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ABSTRACT 


The  Usar  Equipment  (US)  Global  Positioning  System  (GPS) 
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system  up  to  March  1983  is  critiqued.  Our  objective  was  to 
explore  the  existing  configuration  management  plans  in  terms 
of  documentation,  with  specific  emphasis  on  the  feasibility 
of  the  conf igiration  control  plans  for  the  Navy  unique  and 
DoD      ccmmon     items.  Our      conclusion      is      that        the      GPS 

Configuration  Control  Structure  is  fundamentally  sound. 
However,  a  major  problem  of  integrating  the  various  facets 
of  configuration  control  management  exists.  Tc  correct  this 
deficiency,  the  GPS  Program  must  now  obtain  interservice  and 
intraservice  written  agraements  d£  Configuration  Control 
Responsibility  tc  further  specify  and  clarify  each  service's 
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I-    INTRODUCTION 

A.       BACKGBOOND 

Thsre  is  general  agreement  -hat  military  users  wouli 
benefit  from  global  deployment  of  a  precise  naviga-ion 
system.  Frscise  positioning  and  navigation  (POS/NAV)  needs 
for  the  Department  of  Defense  (DOD)  have  -radi-ionally  been 
satisfied  by  a  multitude  of  specialized  equipments  respon- 
sible to  particular  mission  requirements.  The  result  has 
been  a  proliferation  of  POS/NAV  systems  producing  an  aggre- 
gate of  system  facilities  and  airborne,  shipboard,  and 
ground  ussr  terminals  with  varying  degrees  of  accuracy  and 
capabilities.  Deployment  of  the  Slobal  Positioning  System 
(GPS)  will  reverse  this  trend  while  providing  accura-e 
POS/NAV    for   all    military    users. 

Generally  speaking,  the  conduct  of  military  operations 
requires  that  forces  involved  accurately  know  their  posi- 
tion, velocity,  and  time.  The  missions  assigned  to  the 
respective  services  generate  a  broad  spectrum  of  unique  yet 
in  many  cases,  similar  navigation  requirements.  The  degree 
to  which  these  requirements  are  satisfied  directly  affects 
the  outcome  of  military  ventures,  particularly  in  multi-unit 
and    joint   service  operations. 

Global      navigation        requirements      as        stated      by        the 

Assistant   Secretary    of  Defense   For   -cmraunicat ions ,      Command, 

Control,    and  Intelligence   are: 

W=    need   a    system    which    can    provide    accurate   navigation 
anywhere    on  the   glebe,    one    which   is    independent    of    ground 
stations,    since   we   cannot    be   assured   of   the   cooperation   of 
countries   enroute    or  in   the    viciaity   of   a   crisis.      We   need 
a    system    which   is    accurate   enough    to   serve    as    an 
instrument   landing    system,    since   we    cannot    be    certain 
of    the    facilities    which   will    be   available   at   the    airfields 
in    a   given  crisis    area.       We   need  a    system    in   which 
security   is   inherent  in   the   design    and   does   net    ccmprcmise 
the    existence    cr    oosition    of    the   user.      [Ref-     1] 


Th?  NAVSTAB  GPS  is  a  spacs-based  radio  positioning  and 
navigation  system  that  will  provide  extremely  accurate 
three-dimensional  position  (to  within  16  meters  spherical 
error  of  probability),  velocity  (to  within  0.05  me-ers/ 
second)  and  system  time  (to  wizhin  55  nanoseconds)  -o 
suitably  equipped  users  anywhere  on  or  near  (within  500 
miles)  *he  earrh.  The  GPS  consists  of  three  major  segraenrs: 
Space  System  Segment,  Control  Sysxsm  Segment,  and  User 
System   Segment-      [Ref.   2] 

The  operational  GPS  Space  System  Segment  deploys  six 
planes  of  satellites  containing  three  satellites  each.  this 
deployment  will  provide  adequate  satellite  coverage  for 
continuous  and  worldwide  three  dimensional  positioning, 
navigation  and  velocity  determination.  Each  satellite  tran- 
smits a  composite  signal  at  two  L-band  frequencies 
consisting  of  a  precision  navigational  signal  (P  CODE)  and  a 
coarse   acquisition    (C/A   CODE)    navigational   signal.      [Ref.    3] 

The  Control  System  Segment  consists  of  four  widely  sepa- 
rated Monitor  Stations  that  are  located  in  a.  S.  territory 
or  U.  S.  controlled  territory.  The  stations  passively  track 
all  satellites  in  view,  and  accumulate  ranging  data  from  the 
navigational  signals.  Ranging  information  is  processed  at  a 
Master  Control  Station,  located  in  the  Continental  United 
States,  for  use  in  satellite  orbit  determination  and  syste- 
matic  error   correction. 

The  User  Equipment  Segment  consists  of  three  user  sets 
that  will  be  used  in  numerous  host  vehicles.  The  thesis  is 
focused   on   this    segment. 

Using  the  navigation  signals  from  each  of  four  satel- 
lites, the  user  receiver/processor  (RPU)  converts  the 
pseudcranges  and  pseudorange  rates  to  three-dimensional 
position  and  velocity,  and  system  time.  The  position  solu- 
tion is  in  earth-centered  coordinates,  which  c?.n  be 
converted  to      any   coordinate    frame      or   units    of      measure    the 


user  requires.  To  accomplish  th9  navigation  function,  pseu- 
dorange  and  delta  pseudorange  maasurements  are  usad  to 
update   a   running   estimate  of   the   user's   position.      [Hef-    4] 

B.       ACQOISITION    APPROACH 

The  acquisition  approach  for  tha  GPS,  recommended  by  the 
Defense  Systems  Acquisition  Review  Council  (DSARC)  ,  is  a 
step-wise,  design- to-cost  development  and  tasi:  program 
leading  in  successive  phases  zo  an  operational  GPS.  Each 
phase  is  designed  to  build  and  expand  on  -he  previous  phase 
in  an  integrated  and  cohesive  manner.  Phase  1,  Concept 
Development,  concentrated  on  validation  of  design  concepts 
and  developing  a  functional  baseline  through  Development 
Test    and      Evaluation    (DT&S)       of      user   equipment.  Phase   2, 

Demonstration/  Validation,  will  complete  the  DISS  and 
Initial  Operational  Test  and  Evaluation  (IOT(>E)  of  user 
equipment.  Finally  during  Phase  3,  Production/Development, 
the    full   GPS  capability   will   be  achieved.      [Hef.    5] 

Phase  1  encompassed  the  first  of  two  design-build-test- 
design  cycles  to  determine  praferrred  user  aquic!n3nt 
configurations  and  validate  the  conceptual  life  cycle  cost 
models   in   the  design-tc-cost   process.  The   purpose   of  this 

approach  was  to  r aduce  overall  program  risk,  to  reduce 
projsctad  user  equipment  dasign  and  life-cycle  costs  through 
encouraging  innovative  designs,  to  increase  industry  compet- 
ition by  broadening  the  industrial  base,  and  to  fully 
investigate  the  potential  classes  of  user  equipment.  Strong 
emphasis  was  placed  early  in  thase  contracts  on  low  develop- 
ment costs  through  the  use  of  modular  hardware  and  software 
designs,  while  total  life  cycle  costs  were  minimized  through 
the  use  of  common  modules  across  various  host  vehicle  cate- 
gories,   wherever   possible.      [Hef.    6] 
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User  equipmsnt  activities  ia  Phase  2  are  primarly 
concerned  with  develcpmen-  and  -easing  of  prototypes  of  user 
equipment.  Two  contractors  are  developing  the  basic  set 
architecture  for  a  family  of  user  squipment  hardware  to  be 
used      in      all      classes  of      host      vehicles.  This      approach 

provides  commonality  across  all  classes  of  user  equipment 
designed  by  each  contractor  and  should  achieve  zh^  desired 
cost  benefits  in  Phase  3.  The  commonality  designed  into  the 
user    equipment    covers   both    areas    of   hardware   and    software. 

During  Phase  3,  the  user  equipmant  will  move  into  full 
scale  production.  The  family  of  user  equipments  which  best 
meets  the  user's  needs  in  terms  of  performance  and  life- 
cycle-cost    will    be    selected    for   production. 

The  user  equipments  to  be  produced,  as  determined  by 
individual  user  requirements,  will  be  procured  in  large  lot 
buys.  Eventually,  20-30,000  sets  could  be  deployed  by  the 
U.S.  Military  with  a  like  number  deployed  by  cur  allies. 
[Rsf.    7] 

In  summary,  the  three  phased  dsvelopment  and  deployment 
of  the  NAVSTAR  GPS  is  an  evolutionary  process.  Each  step 
provides  extensive  legacy  value  for  th=  next  step. 
Throughout  this  process,  system  level  testing  will  be  accom- 
plished in  order  tc  insure  optimum  system  operation  and 
emphasis  will  continue  to  be  placed  on  obtaining  information 
on  the  utilization  of  all  types  of  user  equipment  for  new 
military   applications  and   tactics. 

C.       PORPOSE/TIME    FRAME  OF   THE    RESEARCH 

The  objective  of  this  thesis  project  is  to  explore  the 
existing  configuration  management  planning  in  terms  of  docu- 
mentaticn,  with  specific  emphasis  on  the  feasibility  of  the 
configuration  control  plans  for  the  Mavy  unique  items  and 
the   DcD    common    items.        A   review      of    existing   DoD,      Navy   and 
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Air  Fores  instructions  and  directives  was  andartak=-n  for  i 
comparison  bas<?  to  evaluate  'he  3PS  configuration  control 
raanagsment  plans.  A  farther  sxudy  of  existing  litera-ure  on 
the  subject  of  configuration  conrrol  of  both  hardware  and 
software,  in  conjunction  with  visits  to  -he  Joint  Program 
Office  (JPO)  in  Los  Angeles,  Ca.  and  Warner  Robins  Air 
Logistics  Center  (WR-ALC)  in  Warner  Robins,  Ga.  completed 
our    research- 

The  research  was  conducted  during  the  September  1982  to 
March  1983  time  frame.  The  GPS  program  was  in  full  scale 
development  and  preparing  for  DSARC  III,  Our  intention  is 
to  present  a  critique  of  the  configuration  control  manage- 
ment: plans  as  they  exis-=d  during  the  research  time  frame. 
Our  interpretations  of  the  documents,  including  our  under- 
standing of  the  statements  and  comments  gathered  -hrough 
interviews  and  telephone  conversations,  are  the  basis  for 
the  conclusions  presented  in  this  thesis.  The  acquisition 
and  configuration  management  plans  are  dynamic;  therefore, 
the  analysis  and  conclusions  are  the  result  of  the  configu- 
ration control  management  plans  as  seen  by  the  researchers, 
up   to   the   March    1983    time   frame. 

D.       ASSUMPTIONS 

A  basic  assumption  concerning  the  configuration  control 
management  of  the  GPS  User  Equipment  (UE)  should  be  noted. 
The  assumption  is  the  determination  of  which  configuration 
items  (CIS)  and  computer  program  configuration  items  (CPCIs) 
are  DcD  common  or  Navy  unique.  The  Navy  unique  items  for 
this  discussion  are  considered  to  be  the  Flexible  Modular 
Interface  (FMI)  and  its  associated  CPCIs.  Antennas  could 
fall  into  the  Navy  unique  category  under  certain  conditions. 
This  thesis  was  limited  to  the  discussion  of  the  FMI  and  its 
computer      programs    as     the      pivotal      unique   item.  It      was 
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considered  by  the  researchers  -chat  if  the  configuration 
control  management  plans  could  support  the  FMI  it  would  also 
be  able  to  support  any  antennas  associated  with  the  GPS  UE 
program. 

The  DoD  common  items  considered  in  this  project  were  the 
Control  Display  Unit  (CDU)  ,  some  antennas  and  antenna  elec- 
tronics and  the  Receiver/  Processor  Unit  (RPU) .  The  RPU 
became  the  area  of  most  concern  due  to  its  being  the  CI  with 
embedded  CPCIs  and  the  unit  that  directly  interfaces  with 
the  FMI.  The  BPU  is  in  very  simple  terms  a  micro-computer 
consisting  of  approximately  80%  software.  The  RPU  in  opera- 
tional form  has  the  software  etched  on  computer  chips  making 
it    firmware. 

The  user  equipment  segment  of  the  GPS  is  compo3*=d  cf 
uniquely  conFigured  ensembles  of  equipment,  called  Sets,  as 
well  as  test  instrumentation  and  Peculiar  Support  Equipment 
(PSE)  .  Each    set      consists   of      the      hardware   and      software 

necessary  to  convert  the  GPS  navigation  signals  into  timing 
data,  positioning  data,  navigation  data,  and  control/display 
signals,  as  required.  The  scope  of  this  thesis  prcject  is 
limited  tc  and  focused  on  the  configuration  control  manage- 
ment   plans    for    the    Sets. 

The  remainder  of  this  thesis  d3als  exclusively  with  the 
user  equipment  segment.  It  is  limited  to  the  configuration 
control  plans  for  the  Navy  unique  and  the  DcD  common  user 
equipment. 


13 


II.    CON FIG 0 RATION   CONTBOL    LI TEH A HI    HB SEARCH 

A.       CONFIGOBATION    MANAGEMENT/CONFIGOHATION    CONTROL 

Ccnf iguration  Managemsnt  (CM)  accepts  the  fac-  that 
changes  occur  during  a  project's  life  cycls.  Configuration 
Management  tries  to  manage  these  changes  and  accept  only  the 
changes   that  offer   a    significant   benefit   -o   the   government. 

As  a  project  moves  through  concepz  exploration,  demons- 
tration and  validation,  full  scale  development  then  into 
production  and  deployment  (phases  0,1,2  and  3)  its  configu- 
ration identification  is  continually  modified.  Accordingly 
the  configuration  of  a  product  is  developed  during  concept 
explora-ion,  determined  during  demonstration  and  validation, 
established  during  full  scale  development  and  maintained 
during   production   and   deployment.      [Rsf,    8] 

In  a  buyer-seller  relationship,  particularly  in  -he 
aerospace  marketplace  where  the  buyer  is  usually  purchasing 
not  only  the  end  product  but  its  design  and  development  as 
well,  the  point  of  departure  or  "baseline"  between  each 
phase  has  significance.  Each  baseline  represents  a  point  of 
decision  by  the  buyer  or  negotiation  between  the  buyer  and 
seller,  or  both.  The  buyer  must  have  some  measure  of  super- 
vision over  the  seller's  activities  zo  assure  -hat  ;  (A)  he 
has  significant  basis  for  making  the  basic  critical  deci- 
sions, such  as  continuation,  cancellation  or  modification  of 
a  project;  (B)  He  is  getting  the  product  contracted  for  at 
all  times;  aad  (C)  The  product  will  be  compatible  with  the 
ether  configuration  items  in  his  complement  of  equipment  or 
associated    project    interfaces.      [Ref.    9] 
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The  overall  objective  of  configuration  management  is  -o 
deliver  tc  zhe  buyer,  both  functionally  and  physically,  -he 
intended  produce  as  specified  by  tae  cont.ract  drawings  and 
specifications.  The  product  configuration  is  identified  to 
the  lowest  level  to  assure  consiszeni;  performance,  quality 
and   reliability. 

Configuration  management  allows  for  the  integrity  and 
continuity  of  technical  and  cost  decisions  related  to  the 
product^s  producibility,  performance,  operation  and  maintai- 
nance  are  recorded  and  controlled  by  Project  Managers.  The 
process  of  configuration  management  encompasses  the  special- 
ties of  configuration  control,  configuration  identification 
and    configuration   accounting. 

The  goal  of  these  operations  is  to  assure  that  the 
delivered  CI  or  CPCI  meets  Form,  Fit  and  Function  require- 
ments. Configuration  refers  to  a  complete  description  of 
the  physical  and  functional  characteristics  of  a  product. 
Configuration  also  applies  to  technical  descriptions 
required  to  build,  test,  operate  and  repair  a  CI/CPCI. 
[Hef.  10]  The  majcr  facets  of  configuration  management  are 
shown    in   Fig.    2. 1. 

Configuration  Control  involves  the  systematic  evalua- 
tion, coordination  and  approval  or  disapproval  of  proposed 
changes  tc  the  design  and  construction  of  a  CI/CPCI  whose 
configuration  has  been  formally  approved  internally  by  the 
company    or   by  the   buyer   or    both.      [Bef.    11] 

Configuration  Identification  refers  to  the  technical 
identification  that  identifies  and  describes  the  approved 
product  configuration  throughout  the  design,  development, 
test  and  production  tasks.  It  also  applies  to  the  identifi- 
cation  of   changes   and  to    produc^    markings. 

Configuration  Accounting  is  the  recording  and  reporting 
of  CI/CPCI  descriptions  and  all  departures  planned  or  made 
from      the      CI/CPCI      through    the      comparisons      of      authorized 
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design   data   and      the    fabricated  and   tasxed      conf iguratior.   cf 
the    CI/CFCI.      [R9f.     12] 

Samaras        and        Czerwinski        staxa  in        their        bock, 

"Fundamentals  of  Configuration   Managaman-" ,    the    key    features 
in   the   configuration   management   process.      They  are; 

1.  Early     and        complete      definition        of     Configuration 
i^anagement  goals,    scope   and  procedures, 

2.  Speed  in    evaluating    and    processing   changes. 

3.  Accurate    identification   and   accounting  of   changes. 

4.  Complete    descriptions   of  changes. 

5.  Close  coordination   among   key      elements   of   the   project 
team. 

6.  Ccoperativa    and  responsive   buyer. 

7.  Minimum    labor   requir aments. 

Tc  achieve  effective  configuration  Jianagement  the 
configuration  manager  must  be  independent  of  quality  assu- 
rance, production,  engineering,  ate.  The  separation  is 
necessary  t.c  achieve  unbiased  control  and  to  prevent  any 
conflicts   of  interest. 

To  assist  the  Configuration  Manager,  a  Configuration 
Control  Beard  (CCB)  is  established.  The  CCB  includes  repre- 
sentatives of  production,  anginearing,  contracting, 
purchasing,  quality  assurance,  maintainability  and  data 
processing.  The  CCB  is  responsible  for  complete  change 
evaluation,  change  planning,  change  incorporation  and  as  a 
result    is   usually  the  final    authority   on   proposed   changes, 

A  typical  Program  Office, and  where  Configuration 
Management  functions  within  that  cffice,  is  shown  in  Figure 
2.2.  The  GFS  configuration  management  structure  is  detailed 
further    in   chapters    4  and   5. 
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B.       HARDHARE   AND    SOPTiARE 

In  ^arly  applications  of  corapatars  to  military  systems, 
the  scfTware's  rcle  was  assentially  as  an  instruc-ion  boolc 
and   the   cost  of    the    software   was    miniaial. 

Secsntly,  ambedded  computer  software  systems  have  become 
a  higher  fraction  of  rhe  total  mili-ary  development  cost. 
As  a  result,  a  reversal  of  software  and  hardware  roles  has 
developed.        Software   has    avoived      from    being   the    computer's 
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set  cf  instructions  to  BEING  tha  systam.  Software  r.ow 
contains  the  description  of  what  the  total  system  is 
supposed  to  do  and  the  hardware  is  the  means  -chrough  which 
the   instructions   are   carried  out. 

The  result  is  that  software  is  a  dominant  and  crucial 
piece  cf  rhs  computer  sysrem.  Software  clearly  warrants  at 
least  the  same  degree  of  developmeQt,  discipline,  quality 
assurance  and  configuration  management  as  the  hardware.  The 
problem  we  face  today  is  that  many  managers  see  software  as 
esoteric  and  mysterious,  causing  greater  anxiety  among  their 
numbers   than  the   more   familiar   hardware. 

Proof  of  the  managerial  inattention  to  software  surfaced 
in  1S75  as  a  result  of  the  Johns  Hopkins  University  Applied 
Physics  Laboratory  (APL)  and  the  aiTRE  Corporation  studies 
of    the   DCB   weapons    systems    software   management. 

The  MITRE  Corporation  revealed  that  software  problems 
stemmed  from  the  fact  that  a  laclc  of  discipline  and  engi- 
neering rigor  applied  consistently  to  the  software 
acquisition  activities.  Some  specific  areas  identified  in 
the  study  that  contributed  to  software  cost  and  schedule 
growth   were:      [  Ref .     13] 

1.  Pccrly  formulated   initial   software   re-iuirements. 

2.  Changing  requirements  and  requirements  growth  during 
the   development   phase. 

3.  Improper  use  cf  standards  and  guidance  documents  in 
specific    procurements. 

The  Applied  Physics  Laboratory  study  resulted  in  17 
recommendations  all  addressed  to  different  topics.  Three 
that    pertain  to    configuration   management    were:      [Ref.    1U] 

1.  Majcr  computer  software  involved  m  weapons  systems 
shculd  be  designated  "configuration  items"  and  be 
deliverable    during   full   scale    development. 

2.  Use  top  down  design,  specifically,  the  use  of  modular 
software    architecture. 
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3.      The   contractor  should      be   required   to   apply      a    higner 

set   of      engineering    practices    to    the      detailed   design 

and   programming  phase  of   development.        This    includes 

a   set  of    standards  covering  program   structure,      size, 

control,      interface,       formal   conventions   on   data   base 

management:  and     demonstration    that   the      standards   are 

reinforced  in   practice. 

An   important      aspect   that   should      be   understood      is   -hat 

every   post    delivery    change   to      software   is   not   a    maintenance 

action   but   a  change    to  the      design  of   the   delivered    package. 

Software      programs      do     not    fail      as      hardware      systems      do. 

Zeroes  and   ones    do   net  wear    out.  Software   systems   have   no 

need    for   classical    maint enanace.         The   inevi-able    results   of 

these      modifications      are      unnecessary    "down"      time      of      the 

system   and   unwarranted  additional   costs. 

The  Program  Manager's  job  is  not  easy  when  dealing  with 
software.  The  Program  Manager  must  realize  software  and 
hardware  are  both  configuration  i^ams.  He  must  determine 
how,  when,  and  by  whcm  changes  to  delivered  software  can  be 
made . 

The  Program  Manager  must  decide  how  much  Preplanned 
Product  Improvement  will  prevail  afzer  -he  CPCI  is  deliv- 
ered. Changes  after  program  delivery  must  be  provisioned 
since  -hese  changes  result  in  par-ial  or  xotal  revision  of 
the  original  software.  Consideration  must,  be  given  to  docu- 
men-ation,  configuraxion  control,  distribution  of  the 
changes,  facilities  used,  scope  of  the  changes,  change  sche- 
dules, effected  activities,  etc.  Overall  the  Program 
Manager  iDUst  truly  appreciate  the  nature  of  the  software  and 
any    modifications  to    it. 

The  point  that  software  and  hardware  are  configuration 
items   can      not    be     over   emphasized.  In   the      case    of      GPS, 

changes      to   software     and  hardware      can    be      placed    into      two 
classifications     (I AM      APR   8  00-14      and   MlL-STD-a83)  .  These 
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changes  are  referred  to  as  Class  I  (changes  that  affect  -he 
current  configurati en)  or  Class  II  (changes  not  affecting 
Class  I  criteria  such  as  document  -ypos,  misspelling,  clari- 
fying  notices,    etc.)  .      [ Ref .    15] 

Requirements  for  documentation  vary  depending  on  the 
phase  and  complexity  of  each  CI/CPCI  and  the  change  i-self. 
Basically,  documentation  falls  in-o  three  categories, 
according   ro  NAVMATINST    4130.13    (draft):      [Ref.     16] 

1.  The  documentation  forwarded  to  the  change  installing 
activities  as  a  package  with  the  implementing 
directive/order  involved  to  properly  install  the 
change. 

2.  The  documentation  required  by  the  technical, 
training,  maintenanace  and  supply  management  organi- 
zations   to   properly    control  and   support   each   change. 

3.  The  documentation  required  by  the  user  activities  to 
properly  operate  and  maintain  the  CI/CPCI  after  the 
change  is   installed. 

In  the  case  of  software,  the  "NAVSTAfi  Global  Positioning 
System  Operational/Support  Configuration  Management 

Procedures"      (draft)         [Ref.    17],  specifically      addresses 

computer      program  configuration      item    documentation.  CPCI 

documentation  comprises   two    disinct   areas: 

1.  Documentation,  including  flow  charts,  engineering 
data  (design,  test,  interface  specifications)  etc., 
required  in  the  development  or  testing  of  a  computer 
program.  This  documentatiDn  will  be  identified  with 
a   CPIN  related  to    the   basic  CPCI. 

2.  Documentation  that  instructs  the  user  so  that  he  can 
operate  or  load  the  computer  programs.  This  type  of 
documentation   will  be   as   a   technical   order. 

NAVMATINSr  4  130- IB  (draft)  does  address  the  contractor's 
responsibilities  which  is  consistent  with  item  1  above. 
NAVflATINST    4130.  IB    says,"   the      contractor    is   responsible    for 
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preparing  the  detailed  production  drawings  and  compat3r 
softwars,  manaf acturing  tha  change  hardware  and  firmware  and 
assembling  the  technical  documentation,  hardware,  firmware 
and  computer  software  into  a  retrofit  kit  to  meet  the 
delivery   schedule   established    by   the    CCBD. " 

The  overall  differences  between  software  and  hardware 
configuration  control  documentation  is  not  significant.  All 
data  delivered  under  a  hardware  or  software  contract  is 
defined  in  the  Contract  Data  Requirement  List  (CDRL)  ,  DD 
Form  1U23.  The  point  is  that  software  is  a  configuration 
item  and  requires  the  Configuration  Management  emphasis  that 
hardware  now  receives.  The  GPS  aanagement  realize  this  fact 
which  is  witnessed  in  the  User  Equipment  configuration 
control      structure.  All      computer      program      changes      must 

proceed  through  two  more  configuration  sub-boards  than  hard- 
ware related  changes.  Software  in  the  GPS  structure  is 
scrutinized  by  the  User  Equipment  Computer  Program  Screening 
Panel  (UE  CPSP)  and  the  User  Equipment  Computer  Program 
Configuration  Sub  Board  (UE  CPCSB)  before  it  proceeds  to  the 
User  Equipment  Joint  Configuration  Control  Board  {US  JCCB)  . 
The  fact  that  software  changes  are  design  changes  not 
maintenance  actions  requires  the  additional  analysis  offered 
by    these   additional   configuration   sub-boards. 

The  GPS  hardware/software  configuration  control  struc- 
ture is  managerally  sound  in  design.  The  ultimate  success 
of  the  program  rests  with  the  involved  agencies  who  must 
realistically  adhere  to  the  provided  policies  and  procedures 
of        the        Operational/Systems  Configuration        Management 

Procedures. 
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C.       EXISTING   GOIDELINES    FOE    CONFIGURATION    CONTBOL 

The  NAVSTAR  Global  Positioning  System  Op^raxional 
Support  Configuration  Management  Pcocsdures  (0/S  CMP)  is 
just  one  publication  xhe  GPS  configuration  control  siructure 
must  follow.  Basically,  the  0/S  CMP  expands  on  rhe  proce- 
dures outlined  in  the  GPS  Joint  Services  Support  Management 
Plan  (JSSMP)  ,  Integrated  Logistics  Support  Plan  (ILSP)  and 
the  Computer  Resources  Integrated  Support  Plan  (CRISP). 
Overall  the  GPS  configuration  control  strucxure  must  abide 
by;  Mil-Std-480A       (Configuration        Control-        Engineering 

Changes,  Deviations  and  Waivers),  Mil-Std-481  (Configuration 
Control  Engineering-Changes,  Deviations  and  Waivers  short 
form)  and  MIL-STD-483  (USAF  Configuration  Management 
Practices,  Systems,  Equipment,  Munitions  and  Computer 
Programs)  . 

Besides  following  the  GPS  regulations,  the  Navy  must  act 
in  accordance  with  their  own  instructions  and  regulations. 
Specifically  they  are;  NAVMATINST  4130.1  (DOD  Configuration 
Management  Procedures)  and  YEL  80-122  (Navy  Computer 
Resources   Management    Plan    (the   Navy   annex   to    the    GPS   CRISP)  . 
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III.    BASELINE    FOR    GPS^tJSER    SHIPMENT 

A.       GENEBIC    BASELINE 

The  phasa  3  GPS  User  Equipmant  will  be  ccmprised  of 
several  integral  compcnents,  each  of  which  will  be  desig- 
nated for  usage  on  multiple  platforms.  These  common 
components  are  referred  to  as  Line  Replaceable  Units  (LRU)  , 
which,  in  turn,  are  composed  of  a  set  of  common  hardware 
replaceable  modules  and  chassis  components  icnown  as  Shop 
Repaceabls   Units    (SRU)  . 

This  approach  is  consistent  with  the  overall  strategy  of 
minimizing  Life  Cycle  Cost  (LCC)  by  minimizing  the  number  of 
platform  unique  elements,  through  the  use  of  common  modules, 
while  satisfying  the  varying  host  vehicle  unique  require- 
ments. The  integration  of  GPS  US  onto  Navy  platforms  will 
be  achieved  by  selecting  the  appropriate  combination  of  LRUs 
necessary  to  meet  the  individual  platform  requirements. 
[Ref.    18] 

The  GPS  system  configuration  management  is  managed 
through  a  series  of  time  sequenced  events  known  as  base- 
lines. The  foundation  of  a  CM  system  "^xists  in  baseline 
management  defined  as  the  application  of  technical  and 
administrative  direction  zo  designate  and  control  the  docu- 
ments which  formally  identify  and  establish  the 
configuration  identification  of  a  CPCI  or  CI  at  specified 
times  during  its  Life  Cycle  i.e.,  functional,  allocated,  and 
product    baselines. 

Configuration  identification  is  tha  current  apprcvad  or 
conditionally  approved  technical  documentation  for  a 
configuration  item  as  set  forth  in  specifications,  drawings, 
and    associated    lists    and    documents.       At    any   time    in   the   life 
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cycle,  the  previously  esnablished  baseline,  together  with 
approved  changes,  constitutes  the  current  configuration 
identification  of  the  system  equipmen-.  The  iden-if ica-ion 
of  the  GFS  CIs/C?Cl3  is  the  basis  for  configuration  control. 
The  required  configuration  of  the  CI/CPCI  is  identified  at 
this  time  by  it.s  development  specifications.  The  achieved 
configuration  will  te  identified  by  its  product  specifica- 
tion, which  cannot  ta  fully  addressed  until  receipt  of  the 
GPS  production  specifications,  drawings,  and  software  docu- 
mentation targeted  for  DSARC  III  in  FY  84.  Therefore;  -he 
configuration  control  management:  structure  has  been  planned 
using  a  generic  baseline.  This  puts  the  necessary  pieces  in 
place  and  will  require  only  minor  modification  once  the 
product   baseline   is    finalized. 

The  following  provides  a  general  description  of  the  GPS 
UE   at   the   LRU  level,     (major   CIs) 

B.       GPS    LBDS 

"*  •  Antenna /^Antenna  Electronics:  The  antenna  and  antenna 
electronics  are  separate  LRUs.  There  are  two  generic 
types  of  antennas  available  for  use  as  part  of  the 
UE,    they    are: 

a)  Fixed    Reception   Pattern   Antenna    (FRPA) 

b)  Ccntrclled    Reception   Pattern    Antenna    (CRPA) 

The  FRPA  is  a  simple  omni-directional  antenna  with  a 
deep  null  at  the  horizon.  The  CRPA  is  a  multiple  element 
array  antenna  with  "steerable  nulls"  that  has  a  similar 
receiving  pattern  to  the  FRPA  under  ambient  jamming  and  Low 
Level  Radio  Frequency  Interference  (RFI)  conditions. 
Additionaly,  these  CRPA  antennas  can  sense  jamming  energy 
arriving  from  a  specific  direction  and  quickly  adapt  their 
receiving  patterns  to  create  nulls  in  those  directions.  The 
number   of    jamming  sources  that   can   be   nulled   is    dependent    on 
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the   number   of  antenna  el^menrs.  The  operation    of   th^   CSFA 

is      self-contained   and     does   not      require      any  host      v^hici-^ 
inf ormaticn   or    interaction. 

2.  Control  Display  Unit  (CDU) :  The  GPS  Control  Display 
Unit  (CDU)  provides  the  operator  with  the  capaoility 
to  control  the  UE ,  input  da-a,  and  observe  UZ  gener- 
ated outputs.  The  GPS  CDU  contains  operating 
controls,  a  data  entry  keyboard,  and  alphanumeric 
displays.  The  CDU  will  ncz  be  required  when  integra- 
tion of  the  Set  is  in  a  platform  -hat  has  an  existing 
CDU  that  can  te  utilized  for  GPS. 
3-  Flexible  Modular  Interface  (FMI) :  The  Flexible 
Modular  Interface  (FMI)  will  perform  the  interfacing 
function  between  the  RPU  and  the  user  platform.  The 
FMI  will  provide  the  GPS  UE  with  the  capability  of 
interfacing  with  analog  and  digital  avionics  equip- 
ment and  may  contain  a  microprocessor  for  data 
manipulation  where  required.  The  FMI  for  each  plat- 
form will  be  designed  to  meat  the  unique  requirements 
of  that  particular  platform.  These  unique  designs 
will  be  based  on  the  strategy  of  utilizing  replace- 
able components  common  to  all  FMIs.  This  functional 
partitioning  approach  will  allow  for  commonality  in 
the  use  of  the  other  LRUs  across  many  Navy  applica- 
tions while  supporting  platform  unique  requirements 
in  the  platform  unique  FMIs. 
^'  Receiver  Processor  Unit  (RPU)  :  The  RPU  performs  the 
signal  and  data  processing.  Three  variations,  each  a 
separate    LRU,    make  up   the    RPU    family: 

a)  High  dynamic,  fast  signal  acquisition  (5 
channel) -for  high  performance  aircraft  and  subma- 
rines 

b)  Medium  dynamic  (2  channel)  -for  surface  ships, 
helicopters,   and    medium   performance  aircraft 
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c)    Manpacic/Vehicular       (1      channel) -for      infantry      and 
vehicular    operations. 
Each   of   the    RPUs    shall    perforin  the   following    functions: 
i)  Receive  and      amplify    signals     transmitted   by 

all    visible    satellites 
ii)         Select      and    acquire      signals      from   the      four 

desired   satellites 
iii)       Track  the  acquired     navigation   signals    (four 

simultaneously      for      the      5      channel,        four 

sequentially    for    the    1    and    2    channel    RPUs) 
iv)         Extract       information        contained        in        the 

received    satelii-e  data 
V)  Measure  the    signal  propagation  error 

vi)         Provide   resistance   to    jamming 
vii)       Compute  position,    velocity,    and   time 
viii)     Generate      self      test    signals      for      UE      fault 

isolation 
ix)         Provide  additional  functions     as    required   by 

platform   configuration   and   mission. 

C.       GPS    OB    CAPABILITY    OPTIONS 

A  major  variable  in  deteraing  the  specific  LRUs 
required,  ths  overall  GPS  UE  procurement,  and  individual 
platform  installation  is  the  extent  to  which  the  GPS  UE  is 
integrated  within  the  host  vehicle.  This  in  turn  has  impli- 
caticns  regarding  the  existing  platform  capabilities  which 
GPS  will  enhance,  or  the  new  capabilities  it  will  provide  to 
the  platform.  The  proposed  hierarchy  of  GPS  UE  capability 
options   available  to    the    platforms  are: 

!•      Stand  Alone:  This    option   provides   stand      alone   GPS 

position  and  velocity  data  to  the  user.  The  CDU  is 
the  sole  source  of  information  entry  and  display. 
The   baseline    equipment    required  consists   of: 
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a)    Antenna/antenna  elec-ronics    (FRPA) 
t)    Rsceivsr/processo  r   unit    (1    channel) 
c)    Control/display   unit 

Area  Navigaticn  and  Instrument  Landing:  This  o prion 
provides  *he  capability  to  perforin  enrcute  waypoint 
navigation  in  which  waypoints  are  either  preset  or 
manually  entered.  In  addition,  instrument  landing 
approach  capabilities  will  be  provided  to  determine 
deviation  from  course  and  giidepath  as  well  as  range 
and  bearing  to  waypoints.  The  highly  accurate  GPS 
three  dimensional  position  daza  could  be  used  for 
ncn-precision  instrument  approaches  to  any  airfield 
whose  coordinates  are  known,  including  uninstrumented 
and  temporary  airfields.  The  baseline  equipment 
required    consists   of: 

a)  Antenna/antenna   electronics    (FRPA) 

b)  Receiver/processor   unit    (2    or   5    channel) 

c)  Flexible    modular    interface 

d)  Control/display  uni- 

Aliqnment  and  Calibration:  This  option  provides  the 
capability  of  utilizing  the  GPS  UE  to  update  the 
platform  cn-bcard  Inertial  Navigation  System  (INS)  or 
other  navigational  aids.  Also  the  other  navigation 
sensors  cn-board  can  be  usei  to  update  or  verify  GPS 
information.  The      baseline        equipment        required 

consists    of: 

a)  Antenna/antenna   electronics    (FRPA) 

b)  Receiver/processor   unit    (2    or    5    channel) 

c)  Flexible    modular   interface 

d)  Control/display   unit 

CciDputer  Update;  This  option  provides  the  capability 
of  utilizing  the  GPS  UE  navigation  data  to  update  the 
platform's  central  or  weapons  computer.  This  capa- 
bility     will    enhance      the      functions      of    the      systems 


28 


interfaced  to   these    computers.  The   baseline   equip- 

ment  required   consists   of: 

a)  Antenna/antenna  electronics    (FRPA) 

b)  Receiver/processor   unit    (2    or    5   channel) 

c)  Flexible    modular    intarface 

d)  Ccntrol/display   unit 

5-  Anti-Jam  Enhancement :  This  option  provides  the  capa- 
bility of  enhancinq  the  anti-jamminq  capabilities  in 
-he  GPS  UE,  there-by  providmq  accurate  position, 
velocity  and  time  data  in  a  hostile  environment. 
Iiplement ation  of  this  option  could  provide  the  plat- 
form with  an  anti-jam  capability  improvement  between 
10  to  30  decibels  [Ref.  19].  The  baseline  equipment 
required    consists   of : 

a)  Antenna/antenna  electronics    (CEPA) 

b)  Receiver/ processor   unit    (2    or    5   channel) 

c)  Flexible   modular    interface 

d)  Ccntrol/display  unit 

D.       CCMPOTER   PROGRAMMING 

Computer  proqraras     for    the   GPS      US   shall    be      desiqned   in 
accordance    with    the    following   requirements:      [Ref.    20] 

1.  Each  computer  program  error  allocation  when  combined 
with  the  related  hardware  error  allocation,  shall  not 
degrade   the    naviqa-ional   accuracy. 

2.  Computer  programs  that  provide  navigation  and  timing 
data  shall  be  desiqned  to  provide  a  graceful  degrada- 
tion of  accuracy  as  measurement  data  becomes 
unavailable  or  unreliable.  Separate  degraded-mode 
programs  shall  not  be  utilized  to  provide  this  capa- 
bility. 

3.  Computer  programs  shall  be  designed  in  a  modular 
fashion    to   allow    for    maximum    computer    program   ccmmcn- 
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ality     among    all     Sets      and     localize   the      impact     of 
changes. 
U.      Assembly    language   may   only   be    used   to   implement    func- 
tions    which        cannot      be      coded      efficiently        in      a 
high-level   program  language. 

5.  All  computer  programs  and  corresponding  documentation 
shall  be  written  in  a  self-consistent  and  uniform 
notation. 

6.  The  Set  executive  computer  programs  shall  be  par-i- 
tioned  to  distinctly  isolaze  t.he  set-unique 
exectutive  control  logic.  The  remaining  general- 
purpose  executive  modules  shall  be  as  common  as 
possible    among  all-se-s. 

7.  All  computer  programs  within  all  the  user  segment 
sets  shall  utilize  a  common  machine-languaga  instruc- 
tion  set. 

8.  All  computer  programs  within  all  the  user  segment 
sets  shall  be  written  in  a  single  high-level  program- 
ming  language. 

9.  Microcode  and  firmware  shall  be  considered  as  soft- 
ware  for    definition    purposes. 

The  configuration  Control  Management  Plan  for  DoD  common 
and  Navy  Unique  CI  and  CPCI  at  the  present  time  is  based  on 
the  allocated  baseline.  Configuration  Control  will  become  a 
management  of  the  product  baseline  after  DSARC  III.  The 
considerations    of  baseline    management   are; 

1.  Determine  the   need  for   a   change. 

2.  Prepare   the    change   justification    package. 

3.  Conduct    in-depth   impact   analysis. 

4.  Review  proposed  changes  with  subsequent  approval/ 
disapproval. 

5.  Update  approved  change    material 

6.  Incorporate  approved  changes  in  CI/CPCIs  and  its 
documentation. 
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Adherence   to  well     defined    procsdurss   is   -he     key    element   in 
controlling     and      documenting   changes      to      baselines.  The 

configuration     control  plan      is     an      attempt   to      define      and 
establish   these    procedures. 
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IV.  CCNFIGDRATION  COHTROL  MANAGEMEMT  STROCTORE  FOR  DOD 

CQMHQN 

A.       DOD    CONFIGORATION    CONTROL 

Configuration  control  is  the  systsmaric  evaluation, 
coordination,  approval,  disapproval  and  impleaien-ca-cicn  of 
approvad  changes  to  any  baseline  [Ref.  21].  Formal  con-rol 
of  the  configuration  of  a  system  or  configuration  item/ 
computer  program  configuration  irem  (CI/CPCI)  begins  with 
the  establishment  of  the  firsT:  baseline  and  continues 
throughout    the    life    cycle 

The  objectives  cf  configuration  control  are  to  attain 
and    maintain:      [Ref.    22] 

1.  An  optimum  degree  of  design  and  development  latitude 
while  introducing  controls  at  the  appropriate  time, 
degree  and  depth  during  each  phase  of  the  life  cycle 
of   the  CI . 

2.  Efficient  processing  and  implementation  of  configura- 
ticn   changes. 

3.  Ccaplete,  accurate  and  tiaely  documentation  of  the 
CI's  configuration  consistent  with  total  program 
needs. 

U.      The   required    level   of   operational   readiness,    support- 
ability,         interchangeability        and      interoperability 
through      standardization   and      control      of    design      and 
change   proliferation. 
5.      Monitor    life    cycle  cost   effects   of    ECPs. 
Government        configuration        control      is        governed        by 
DOD-STD-uaO    or    MIL-STD-USI,    as   appropriate.      These   standard- 
ization  documents  help  identify   the      full   impact    of    proposed 
changes      to   established     configuration      baselines    and      their 
subsequent   current    configuration    identification. 
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Control  Df  all  changes  is  a  coordinated  process  of 
documentation,  justification,  systematic  evaluation,  deci- 
sion, release,  implementation,  reporting  and  mcnitcring 
between  the  office  of  primary  responsibility  (OPR)  and  the 
contractor  for  as  long  as  the  contractor  is  invoivad  with 
the  program.  The  OPR,  during  development  and  transition,  is 
the    JFO   and  the    OPR    becomes    the  JSSao   after   PMRT    in   ?Y    87. 

Proposed  changes  may  be  initiated  by  the  0?R,  the 
contractor  or  any  activity  that  has  an  interest  in  the  CI. 
Activities  outside  of  the  OPR  must  submit  changes  to  the  OPR 
for  consideration.  The  OPR's  control  over  proposed  changes 
is  limited  to  those  that  have  an  effect  on  the  current 
configuration     identification   of      the   CI.  The    method      for 

proposing  changes,  the  documentation  which  describes  the  CI 
and  the  related  criteria  which  limits  the  OPR*s  control  are 
clearly   defined    in    the  contract    regairements. 

All  change  proposal  initiators  must  establish  the  basic 
factors  of  ;  the  description  of  the  change,  need  for  the 
change  and  the  conditions  of  accomplishment  capability  (i.e. 
change  accomplishment  location,  capability  reguirements  for 
personnel  and  the   time  schedule)  .  The   change    initiator  is 

responsible  by  the  contract  to  establish  the  basic  factors, 
determine  the  applicable  criteria  with  supporting  data  and 
evaluate   the  criteria  and  data. 

Change  proposals  that  do  not  offer  significant  benefit 
to  the  government  are  cancelled.  Necessary  or  beneficial 
changes  are  those  which;  correct  errors  or  deficiencies, 
resolve  non-availability  of  parts  and  components,  effect 
substantial  life  cycle  cost  savings,  prevent  stoppage  or 
slippage  in  schedules,  effect  advancements  in  technology  and 
any    change   that    changes   the    mission    element   need.      [Ref.    23] 

The  OPR  is  responsible  for  establishing  priorities  and 
time  spans  for  change  proposal  processing,  based  on  the 
nature   and     relative    urgency   of     the    change.  The    proposed 
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priority  is  assigned  by  the  initiator  and  stands  unless  th3 
OPR  has  a  valid  rsascn  for  changing  it.  The  OPR  establishes 
detailed        operating        procedures,  configuration        s-catus 

accounting  records  and  other  appropriate  progress  techniques 
necessary  for  timely  processing  of  "::he  change  proposal.  The 
OPR  controls  the  processing  of  changes  to  avoid  any  unneces- 
sary drlays  which  cculd  prevenx  timely  incorporation  of 
changes  during  producxion,  result  in  increased  acquisition 
costs  or  deny  DOD  activi-ies  benefits  from  the  change.  The 
OPR  can  wirhold  a  change  proposal's  "production  cut-in"  for 
subsequent,  rather  than  current,  production  lot  to  fulfill 
the  requirement  of  giving  the  contractor  sufficient  notifi- 
cation in  ordsr  to  plan  and  perform  turn  around  and  recyclic 
engineering   and    production    actions. 

The  OPR  controls  the  flow  of  change  proposals  through 
use  of  a  "log"  that  is  used  to  establish  realistic  targets 
for  each  proposal  and  provides  the  basis  for  program  manage- 
ment evaluation  as  to  the  expeditious  flow  and  s-iaius  of 
each    change. 

Tc  provide  for  proper  change  proposal  coordination, 
evaluation,  processing,  approval,  disapproval  and  implemen- 
tation cognizant  DOD  components  establish  a  Configuration 
Control  Eoard  (CC3) .  The  CCB  is  -he  official  agency  to  act 
en   all   changes. 

The  CCB  is  composed  of  chartered  representatives  from 
all  affectid  fields  such  as  engineering,  contracting, 
quality  assurance,  etc.  Each  representative  presents  his 
official  position,  based  on  his  specialty,  to  the  CCB.  The 
CCB  chairman,  usually  the  Program  Manager  (PM)  ,  ma!c=s  the 
final  decision  on  all  changes  which  are  documented  as  CCB 
Directives  (CC3D)  or  CCB  Requests  (CCBR) .  The  CC3D/CCBR»s 
contain  each  CCB  member's  opinion,  the  implementation  need 
date,  the  implementation  schedula,  contractual  methods  and 
identity   of   responsible   activities. 
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All  change  svaluations  take  into  account  the  r^^la-ive 
merits  of  production  cut-in  and  inventory  retrofitting 
versus  operating  and  supporting  inuiri-  configurations  of  t.h3 
CI.  The  impact  of  not  making  ths  change  at  all  is  always 
considered  as  an  alternative. 

Changes  beyond  the  scope  of  the  CC3*s  authority  such  as 
changes  tc  the  program's  production  schedule,  mission 
element  need  or  program  cost,  require  Office  of  the 
Secretary   of  Defense    (OSD)     or   DOD   component   approval. 

B.       GPS    CONFIGOHATION   CONTROL 

''  •      Ma^cr  Agencies 

The  major  agencies  for  GPS  are:  [Ref,  2U  ] 
^)  Office  Of  Primary  Responsibility  (OPR)  :  The  OP R 
for  the  operational/support  configuration  manage- 
ment procedures  is  the  GPS  Joint  Services  System 
Management  Office  (JSSMO)  ,  after  PMRT  scheduled 
for      FY        87.  All        proposed      changes        to      the 

operational/support  configuration  management 

procedures      are      submitted        from      the      respective 
service   command  to   the   GPS    JSSMO    for   final  action. 

b)  Services  Involved :  The  prime  GPS  users  are  the 
Air  Force,  Army,  Navy,  Marines,  NATO  and  Defense 
Mapping  Agency  (DMA).  User  equipment  (UE)  1 9st 
host  vehicles  include  the  QSAF  B-52  bomber  and 
F-16A  fighter;  the  Navy  SSN-700  submarine,  CV-59 
aircraft  carrier  and  the  A-6E  attack  aircraft;  the 
Army  UH-60  helicopter,  M-60  tank  and  the  soldier 
himself  (manpack  1  channel  version).  DMA  and  NATO 
test  host  vehicles  will  be  identified  at  a  later 
date. 

c)  Contractors:  During  Phase  One  (Demonstration  and 
Validation)      of      the   overall   GPS      program    schedule 
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fcur  contractors  were  selscrad  for  UE  daveiopm^nt 
during  Phase  II-A .  Two  contractors  were  salac-ed 
from  these  four  for  UE  full  scale  development 
during  Phase  II-B:  Magnavox  and  Rockwell-Collins. 
^)    Executive    Service :  DOD   single      manager    policies 

direct  -cha  services  zo  cantralize  management  and 
configuration  control  whan  multi-service  rasources 
are  involved.  As  a  result,  tha  Air  Force  has  been 
designated  the  Executive  Service  (single  manager) 
for  the  GPS  program  and  is  responsible  for  the 
centralized  management  and  configuration  control 
of  GPS  hardware  and  software  sys^ems. 
The   prime   focal   points   for   GPS   are:      [Ref.    25] 

1.  Headquarters  USAF:  Provides  management  of  GPS 
computer  rasources  and  ensures  policies  and  pr^^ce- 
dures  are  consistent  with  applicable  regulations  and 
directives. 

2.  Air  Force  Systems  Command  (AFSC)  :  Responsible  for  the 
development,  acquisition,  transfer  and  turnovar  of 
the  GPS  system.  The  responsibility  has  been  dele- 
gated to  the  Space  Division  (AFSC/SD)  and  AFSC/SD  has 
formed  a  Joint  Program  Office  (J?0)  to  manage  GPS 
multi-service    involvement. 

3.  GPS  Joint  Program  Office  (JPO)  :  The  JPO  has  full 
management  responsibilities  prior  to  Program 
Management  Responsibility  Turnover  (PMRT) .  The  JPO 
is  the  GPS  System  Manager  (SM)  up  to  the  P«RT  date, 
for   the    overall  program. 

4.  Air  Force  Logistics  Command  (AFLC) :  AFLC  implements 
all  applicable  instructions,  regulations  and  direc- 
tives after  PMRT  and  AFSC  turnover,  for  DoD  common  UE 
items.  AFLC  has  designated  Warner  Robins  Air 
Logistics  Center  (WR-ALC)  as  the  post-PKRT  Systems 
Manager       (SM)  .  Because      GPS      is      a      joint      service 
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prcgram,      the    Navy  and    Army   will   have   represen-^a-tivss 
at    WE-ALC. 

C.       GPS         CONFIGORATIOM         CONTROL         RESPONSIBILITIES  PRIOR 

TO/AFTER   PMRT 

The  objective  of  PMRT  is  to  accomplish  an  orderly, 
timely  and  efficient  transfer  of  overall  Program  Management 
Responsibility  (PMR)  at  the  earliest  practicable  date  during 
the  Production  and  Deployment  Phase  (Phase  3)  .  This  is 
scheduled   for  FY   87. 

The  Transfer  Working  Group  (TWG)  ,  established  by  the 
Program  Manager,  develops  the  schedule,  coordinates  the 
Transfer  and  fabricates  an  overall  transfer  plan  for  the 
program. 

PMRT  planning  for  joint  service  programs  justifies  the 
interrelationships  and  functional  responsibilities  cf  the 
executive  and  supporting  services  that  become  effective  at 
the  PHRT  date.  Therefore;  after  PMRT  the  Army  and  the  Navy 
will  report  to  the  JSSMO  vice  the  JPG.  The  USAF,  as  s-ated 
earlier,    is   the    GPS    Executive   Service. 

Prior  -^o  PMRT,  the  JPG  has  configuration  management 
responsibilities  for  the  entire  GPS  program.  The  GPS  JPG 
has  developed  and  implemented  a  cost  effective  configuration 
management  program  by  utilizing  the  contractor's  internal 
configuration  management  practices.  The  JSSMG  begins  mcii- 
toring  the  configuration  management  at  the  beginning  of 
Phase  III  and  stops  monitoring  after  PMRT  when  it  assumes 
total   program  configuration    management   responsibility. 

The  Transition  Phase  begins  when  the  JPG  reponsibility 
is  gradually  turned  over  to  the  JSSMG  and  continues  tc  the 
PMRT.  The  GPS  JPG  Joint  Configuration  Control  Board  (JCCB) 
retains  final  approval  for  all  configuration  changes  during 
the  Transition  Period.  The  configuration  management  func- 
tion     continues      to    be      administered      by      the   GPS      JPG      with 
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increased  participation  from  the  support  commands  and  user 
organizations  until  the  PURT  data  when  all  GPS  system  base- 
lines and  related  documentation  are  finalized  then 
transferred   to    the    JSSMO   WR-ALC. 

After  PMRT  the  JS5M0  at  «R-ALC  has  full  joint  service 
authority  and  responsibility  for  configuration  management. 
The  JSSMC  has  configuration  control  of  every  GPS  unit  except 
for  the  Flexible  Modular  Interface  (FMI)  and  its  internal 
software  which  is  unique  to  a  single  host  vehicle.  In  this 
case  the  FMI  is  managed  by  the  host  vehicle  System 
Manager  (SM)     or    Program  Manager    (?M)  . 

The  Joint  Service  System  Manager  (JSSM)  establishes  the 
GPS  Joint  Configuration  Control  3oard  (JCCB)  at  Warner 
Robins      Air   Logistics     Center    (WH-ALC)  .  The      GPS   JCCB     is 

tasked  with  controlling  the  configuration  for  the  entire  GPS 
hardware  and  software  systems  except  for  the  host  vehicle 
unique   FMI    units  mentioned    above.  The   JCCB  is    the   regula- 

tory body  for  the  subordinate  configuration  control  boards 
shown    in   Figure    4.1. 

The  subordinate  configuration  control  boards  functions 
are:      [  Ref .    26] 

1.  GPS  JCCB  Working  Group:  The  working  group  serves  as 
the  technical  staff  to  the  GPS  JCCB  and  reports 
directly    to   the  chairman. 

2.  GPS  Control  Segment  Configuration  Control  Board  (CS 
CCB) :  The  CS  CCB  is  responsible  for  all  configuration 
control  of  the  Control  Segment  with  ■  approval 
authority  to  approve  Class  1  changes  that  do  not 
impact  -he   space   vehicls   and/or    user   equipment. 

3.  GPS  Control  segment  Computer  Program  Sub  Board  (CS 
SPCSB):  The  CS  CPCSB  may  approve  Control  Segment 
Class  2  changes  on  CIs  and  computer  program  configu- 
ration items  (CPCI»s)  identified  in  the  CS  CPCSB 
charter. 
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U.  GPS  Ccntrol  Segment  Configuration  Sub  Board  (CS  CS3) 
at  SAC/MCS  (Strategic  Air  Command/Master  Control 
Station) --The  CS  CS B  at  SAC/MCS  operates  similar  to 
the  one  at  WR-ALC  except  it  may  approve  class  2 
organic  software  changes  and  emergency  class  1 
changes  if  required  zo  maintain  satellite  orbital 
configuration. 

5.  GPS   Control    Segmen-c    Computer      Program   Screening   Panel 
(CS   CPSP) :      The  CS   CPSP    is  responsible   for    validating 
proposed      changes   and      preparing   recommendations      for 
submission   to   the   CS    CPCSB/WR- ALC. 

6.  GPS   User    Equifment   Joint      Configuration   Control    Board 
(UE   JCCB) :      The  JSSM    chairs     the    QS   JCC3    and    approves 
class   1    changes  that    do      ncc   impact    the  space   vehicle 
or  the  control  segment    and  all   class   2   changes. 

7.  GPS  UE  Computer  Program  Screening  Panel  (UE  CPSP): 
The  UE  CPSP  functions  in  the  same  capacity  as  the  CS 
CPSP  with  respect  to  validation  of  proposed  changes 
and  recommendations  to  the  UE  Computer  Program 
Configuration    Sub    Board. 

8.  GPS  UE  Computer  Program  Configuration  Sub  Board  (UE 
CPCSB):  The  UE  CPCSB  reports  to  the  UE  JCCB  and  may 
approve    class    2  changes   on   the   User   Equipment. 

9.  PM/SM  Affected,  U3AF,  USA,  U3N  and  other  agencies  all 
have  CCB*s  that  report  to  them  on  configuration 
ccntrol    issues   germane   to   their   respective    service. 

D.       GPS    USEE    SEGMENT    DEFICIENCY    REPORT/CHANGE    PROCEDORES 

User  activities  below  the  depot  level  prepare  and  submit 
UE  deficiencies  and  change  proposals  to  the  respective 
service    CCB.  The    flow    chart      for   processing      user   segment 

deficiency   reports   and  change    proposals      is      shown    in    Figure 
a. 2. 
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Figure  4.2  points  out  the  successive  chain  of  beards  and 
sub  beards  that  must  revisw  then  approve  or  disapprove  each 
change  proposal.  Depending  on  priority  (emergency , urgent  or 
routine)  changes  will  be  implemented  individually  or  held 
for  the  next  block  release.  This  decision  will  be  made  by 
the  JSSM  and  based  on  the  service  system  and  using  activi- 
ties requirements.  If  change  requests  are  held  for  block 
release  a  time  lapse  of  one  year  or  more  could  conceiveably 
elapse  before  the  user  activity  witnesses  the  final  product 
of    a    change   proposal. 

Configuration  Status  Accounting  is  used  to  coordinate, 
record  and  report  all  the  configuration  changes  affecting 
configuration  items  and  computer  program  configurations 
items  to  the  Program  Manager,  MIL-STD-432A  governs  the  use 
of  any  data  content  and  format  necessary  to  perform  status 
accounting.  Status  accounting  is  a  continual  process  suple- 
mented  by  Physical  and  Functional  Configuration  Audits, 
These  audits  should  be  performed  at  a  time  interval  deter- 
mined by  the  requirement  for  updated  baselines.  With  the 
block  change  concept  the  audits  should  precede  the  implemen- 
tation of  the  block  change.  Status  accounting  records  the 
baseline  (approved  configuration)  and  the  implementation 
status  of  changes  to  the  baseline.  This  verifies  whether  or 
not  the  decisions  of  the  GPS  CCB's  are  being  implemented  as 
directed.  Timely  and  accurate  change  reporting  by  the 
contractor  or  GPS  activity  is  paramount  for  a  precise 
configuration  control  system. 
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V.    CONFIGDRATIQN    CONTROL    MAMGEMENT    STROCTORE    FOR    NAVY 

UNIQUE    ITEMS 

This  chapter  is  limited  to  the  function  of  configuration 
control  for  Navy  Unique  User  Equipment  Items  of  the  GPS 
system.  Consideration  will  be  given  ro  the  proposed  manage- 
ment structure  to  facilitate  this  function  and  how  this 
function  interfaces  with  the  configuration  management  func- 
tion   of   the   DoD    common  WE   segment. 

A.       MAJOB    AG£NCIES/R£IATIQH SHIPS 

The   United    States  Air  Force      is   the    executive   agency    for 

the  GFS  program,  and  is  responsible  for  providing  central- 
ized and  integrated  management  of  DoD  common  user  equipment 
which  will  be  in  multi-service/  agency  use.  As  the  execu- 
tive agency,  the  Air  Force  is  responsible  for  maintaining 
the  commonality  and  standardization  of  all  DoD  common  equip- 
ment. The  retention  and  protection  of  GFS  user  equipment 
commonality  and  standardization  are  obligatory  management 
responsibilities.      [  Hef .    27] 

The  Navy's  GPS  Program  encompasses  the  user  equipment 
for  aircraft,  surface  ships  and  submarines,  with  the  use  of 
all  three  GPS  systems  (single  channel,  dual  channel,  five 
channel) .  The  wide  application  of  GPS  in  the  Navy  brings 
into  play  the  three  System  Commands  (NAVAIR,  NAVSEA, 
NAVELEX)  and  the  Chief  of  Naval  Material  (P.^-l)  .  The  very 
diverse  characteristics  of  the  respective  operational  plat- 
forms and  weapon  systems  dictate  procedural  variations  in 
the  implementation  of  effective  management  functions.  The 
Navy  has  specific  responsibilities  for  ensuring  the  ccraraon- 
ality      and      standardization      of      software      and     hardware     of 
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Navy-uniqii€  user  equipment  and  for  providing  support  zo  -h? 
Air  Force  in  maintaining  commonality  and  sxandardizatior.  for 
DoD    ccmmcn   equipment. 

Figure  5.  1  graphically  identifies  the  organizational 
interrelationships  of  the  Navy  System  Commands  and  the  JPO, 
both  before  and  afzer  PMET,  The  major  effec-  by  PMRT  on  rhe 
support  management  structure  for  tha  Navy  is  the  change  from 
JPO    to   JSSMC  final   approval    authority. 

The  GPS  JPO  has  full  program  management  authority  and 
responsibility  until  the  planned  PMRT  occurs  in  FY  87. 
Following  the  PMRT,  those  responsibilities  will  be  assumed 
by  the  GPS  JSSMO  located  at  Warner  Robins  Air  Logistic 
Center    (WE-ALC)  . 

The  Navy  Support  Management  Structure  prior  to  PMRT 
is  headed  by  the  Program  Manager  PME-106-2  and  is  assisted 
technically  by  the  SYSCOMs  with  consultation  provided  by  the 
CEA,         LFAs    and      the    PSSAs.  The      headquarters    element      is 

responsible  for  setting  the  overall  management  policies  for 
the  Navy  Program,  including  the  design  and  implamentaticn  of 
the  total  Navy  program  organization  structure,  for  dele- 
gating administrative  and  configuration  management 
resposibilities  and  for  providing  direction  to  and  funding 
of  program  participants.  The  Navy  support  management  struc- 
ture remains  the  same  after  PMRT  sxcept  it  now  reports  to 
the  JSSMC  via  the  Navy  Configuration  Control  Board,  which 
will    be   chaired    by    PME-106-2. 

PME  106  has  the  overall  responsibility  and  authority  for 
all  phases  cf  the  Navy  GPS  program  as  shown  in  Figure  5.1. 
PME  106  is  the  central  management  activity  responsible  for 
the  total  Navy  acquisition  management  of  the  Navy  GPS  UE 
program.  Responsibilities  include  Configuration  Management, 
Acquisition        Logistics,  Specifications,  Acquisition, 

Cataloging,  Provisioning,  Maintenance  and  Interservicing, 
Spares      Requirements,        Budgeting     and      Funding,         Financial 
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Management, Training,  and  UE  Installations.  PME  106-2  is 
directly  responsible  to  PME  106  for  all  GPS  related  .-nat-ers 
and  interfaces,  and  is  also  t.he  Navy  Deputy  Program  Manager 
at   the   JPO. 

ELEX-08  is  the  central  management  activity  responsible 
for  total  Navy  ILS,  Systems  Effectiveness  Engineering 
Program,  Maintenance  Effectiveness  and  Supply  Support  of  the 
Navy    GPS    UE    program. 

The  second  principal  element  of  the  Navy  GPS  support 
management  structure  is  comprised  of  the  designated  support 
activities  participating  in  the  development,  testing,  evalu- 
ation, support  and  utlization  of  the  GPS  system.  This  group 
of  organizations  includes  the  CEA,  LFAs  and  PSSAs  with 
responsibilities  for  various  Navy  laboratories,  depots,  test 
and  evaluation  activities  and  user  activities.  The  active 
membership  of  this  group  will  change  from  time  to  time  as 
the  GPS  system  evolves  from  development  to  ultimate  deploy- 
ment. Organizationally,  this  element  is  depicted  in  Figure 
5.1.      [Ref.    28] 

The  contractor  position  in  the  support  management  struc- 
ture is  an  advisory  member.  The  contractor  is  a  critical 
contributor  of  ir.formation  concerning  design  and  production 
management,  which  ties  directly  into  configuration  control 
management.  The  contractor  will  also  supply  all  technical 
support  fcr  the  first  2  to  3  years  prior  to  the  Navy's  take 
over  cf  crganic  support.  The  benefit  from  the  contractors 
participation,  will  rely  heavily  upon  the  amount  of  coopera- 
tion and  effort  that  the  contractor  places  on  the 
development  of  the  GPS  system  and  the  attitude  taicen  in  the 
adviscry   role. 

The  GPS  creates  the  need  for  numerous  vertical  and  hori- 
zontal relationships  within  the  Navy  for  configuration 
control      management.  The    support      structure     depicted     in 

Figure   5.1    indicates   these    relationships    and   also    the   single 
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interface   betwasp.      PME   106-2   and   the      JPO   prior   -c      PMBT   and 
JSSHC   after    PMRT. 

B.       CONFIGDRAriOB   MANAGEMENT    STRUCTORE    HARDWA,RE/SOFTWARE 

The  Navy  configuration  management  structure  was  planned 
around  the  most  complex  case.  The  complexity  of  the  FMI  is 
a  product  of  the  amount  of  embedded  computer  programs  being 
designed  into  the  FMI  and  the  interface  between  the  FMI  and 
the  RPU.  The  design  possibilities  lie  between  two  extremes. 
At  the  one  extreme  is  what  we  will  call  the  "smart"  FMI,  it 
would  be  capable  of  preprocessing  all  data  flowing  between 
the  RPU  and  the  host  vehical  and  would  not  require  a  stand- 
ardized I/O  interface  between  the  R?[J  and  the  FMI.  This 
implies  that  the  smart  FMI  would  contain  all  tne  required 
computer  programs  to  process  all  data  concerning  the  GPS  and 
be  capable  of  formatting  the  data  for  all  host  vehicles. 
The  design  would  allow  for  the  maximum  commonality  among 
FMIs  for  the  Navy  host  vehicles.  Making  this  FMI  program- 
mable to  accommodate  the  integration  aspect  of  the  different 
host  vehicles  could,  at  the  extreme,  require  only  one  FMI 
configuration,  along  with  separate  software  programs  that 
could  be  loaded  into  the  FMI  for  each  type  of  platform.  At 
the  ether  extreme  is  what  we  will  call  the  "dumb"  FMI.  In 
very  simplistic  terms  the  FMI  would  be  nothing  more  than  a 
junction  box  that  would  accept  data  from  a  standardized  I/O 
interface  between  the  RPU  and  the  FMI  and  direct  the  data  to 
the    appropriate      sensors   in    the      host    vehicle.  This    would 

most    likely   require    a  unique   FMI    for    every    platform. 

The  FMI  baseline  is  presently  specified  in  generic  terms 
and  the  product  configuration  baseline  will  not  be  estab- 
lished until  the  production  decision  is  made  at  DSARC  III 
sometime  in  FY  3U.  Both  contractors  are  working  under  a 
Fixed   Price     development    contract,      which    limits      the    Navy's 
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input  of  precise  design  tradeoffs  during  the  FMIs  devslcp- 
iD-ent .  Given  zhis  fact  the  mcst  probable  outcome  will  be  to 
purchase  initially  the  FMIs  that  are  designed  by  -he 
contractcr,  and  tested  during  lOT&E.  Therefore;  to  be  able 
to  do  configuration  control  management  the  need  tc  develop 
plans  for  the  most  complex  case  based  on  the  proposed 
contractor  designs  requires  a  management  structure  that  will 
be  capable  of  handling  both  hardware  and  software  configura- 
tion control.  The  structure  must  also  be  designed  to 
interface  with  all  the  various  activities  and  support 
elements   involved  in    GPS. 

The  Navy  configuration  management  structure  is  headed  by 
the  program  manager,  PME  106-2  and  assisted  technically  by 
the  SYSCOMS,  with  consultation  provided  by  the  System 
Management  Office  (SMO)  at  CSA,  System  Support  Office  (SSO) 
at  the  IFAs  and  the  Platform  System  Support  Activities 
(PSSAs)  .  Together  these  activities  maJce  up  the  headquarters 
element,  which  is  responsible  for  the  overall  program  direc- 
tion. Other  Activities  provide  specialized  assistance  as 
required.  [Ref.  29]  The  headquarters  element  organization 
relationships  are   depicted    in    Figure    5.2. 

During  the  development  phase  and  prior  to  the  establish- 
ment of  the  NCCB,  LFA  CEBs,  the  developing  contractor 
submits  all  change  proposals  directly  to  the  J?0  prcgram 
manager  [Ref.  30],  who  has  final  approval/disapproval 
authority.  The     contractor        performs      the      configuration 

control  management  function  and  documentation  during  this 
phase   and   coordinates  his   actions   through   the   JPO. 

The  Navy  Configuration  Management  Structure  (CMS)  comes 
into  play  during  the  transitition  phase  from  contractor 
support      to    Navy      organic   support.  This    structure      relies 

heavily  on  the  configuration  management  data  that  is  devel- 
oped and  updated  by  the  contractor,  with  inputs  by  by  the 
Navy    representative      in   the    JPO.  During   this      phase,      and 
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after  the  NCCB  and  LFA  CRBs  have  been  established,  the 
contractor  will  simultaneously  subait  all  change  proposals 
to  the  NCCB  chairman  and  the  JPO,  who  retains  the  approval/ 
disapproval   authority  throughout   the    transition    phase. 

The  contractors  production  management  plans  require 
coordination  with  the  JPO  during  the  development  and  transi- 
tition  phase.  This  coordination  is  made  more  difficult  due 
to  the  fact  that  the  contractor  is  working  under  a  fixed 
price  contract  and  any  changes  require  contract  negotiation. 
The  contractors  production  plan  along  with  the  product 
configuration  will  become  firm  at  the  conclusion  of  develop- 
ment and  prior  to  production  of  the  GPS  UE.  The  contractors 
production  plan  will  influence  the  cost  and  the  ease  of 
incorporating  changes  into  the  design  during  the  production 
period.  The  worst  case  planning  concept  implies  the  plan- 
ning for  numerous  changes  during  this  period.  Therefore;  to 
implement  changes  the  production  plan  will  have  to  be  flex- 
ible   and    flexibility    normally    means   a   greater  cost. 

The  support  phase  will  coincide  with  the  AF  PMRT,  which 
is  scheduled  for  FY  87.  During  this  phase  all  contractor 
change  proposals  affecting  the  Navy  UE  CIs/CPCIs  will  be 
submitted  to  the  LFAs  for  inclusion  on  the  agenda  and 
presentation  at  the  CHB  meeting.  This  EC?  flow  is  included 
in    Figure   5. 10 . 

The  Navy  configuration  control  management  plans  rely  on 
the  establishment  of  the  NCCB  and  CRBs  early  in  the  transi- 
tition  phase.  Along  with  their  establishment  a  data  system 
must  be  established  to  accept  the  configuration  data  (i.e., 
product  baseline)  from  the  contractor.  The  data  system 
should  handle  not  only  the  Navy  unique  UE,  but  also  the  data 
interface  with  the  DoD  common  UE  items.  This  data  will 
undergo  continuous  update  during  the  transition  and  support 
phase.  The  data  must  be  available  and  in  useable  form  to 
facilitate   the      configuration   contrDl      function.         The      Navy 
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needs      to      know    sxactly      what     items      it      has   and      whaz      -he 
conf igura-cion  of  each  item    is    in   real    -erms. 

Planning  the  configuration  management  struc-ure  around 
the  most  complex  case  implies  that  the  support  facilities 
for  configuration  control  be  established  ro  support  the 
configuration  control  managemenx  of  both  hardware  and  soft- 
ware. To  accomplish  the  configuration  control  of  software, 
a  minimum  of  three  Navy  Software  Laboratories  and  two  Land 
Base  lest  Sites  must  be  established.  This  arrangement  of 
labs  is  depicted  in  Figure  5.3,  The  software  laboratories 
at  XIFA  and  ALFA  could  be  eliminated  with  the  use  of  a  dumb 
FMI.  The  software  laboratory  at  the  CEA  will  be  necessary 
under  either  concept  to  allow  for  centralized  management  and 
first  order  impact  studies  of  ECPs.  The  pivotal  roles  in 
the  management  structure  are  the  roles  played  by  CEA,  XLFA 
and    ALFA. 

">  •      Central    Engineering    Activity    (CEA) 

The  CEA  acts  as  the  NAVELEX  SYSCOM  technical  agent 
for  in-service  engineering  for  the  3PS  system.  As  such,  the 
CEA  supports  PME  106-2  in  ensuring  that  the  GPS  UE  remains 
continually  effective  and  in  combat  ready  state  for  fleet 
use  as  long  as  it  is  part  of  the  Navy  inventory.  CEA  will 
provide  the  central  configuration  control  management  func- 
tion   for    the   Mavy  GPS   UE. 

It  is  the  opinion  of  the  researchers  that  the 
distribution  of  UEs  throughout  the  Navy,  as  well  as  the 
broad  interest  in  utilizing  the  mission  advantages  that  GPS 
can  provide,  will  result  in  a  continuing  stream  of  hardware 
and  software  changes.  The  largest  amount  will  be  software 
changes,  because  the  GPS  is  approxiamately  80%  software. 
These  inputs  will  get  to  the  CEA  through  various  media. 
Inputs  from  the  fleet  activities  and  the  SYSCOMs  will  be 
rouzed   via  the    respective   LFA   to   the    CEA. 
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Figure  5.3         SOFTWARE    LABS/LAHD    BASE    TEST    SITES. 

Information  will  be  coasDlidated  by  an  initial 
screening  group  -chat  will  rsview  all  incoming  da-a  and 
sumraarizs/catagorize  problems,  issues,  etc.  in  a  concise 
format.  These  summaries  will  be  grouped  into  three  catego- 
ries   fcr   assessment    and   rssponse.      [ Ref .    31] 

1.  DOD    COMMON/NAVY    COMMON 

2.  DOD    COMMON 

3.  NAVY    AIR/SEA    UNIQaE 

This  process  is  graphically  displaysd  in  Figure  5.4. 
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Figure  5.4         INPOTS    TO    CEA. 

Each  of  the  CEA  snginsering  sections  and  SYSCOM 
component  uni^is,  woricing  in  coordination  with  each  c-her 
will  determine  problem  definitions,  solutions,  specification 
to  implement  new  requirements,  objectives  to  deal  with  tech- 
nical issues,  system  enhancements  to  utilize  technological 
advancements,  work  packages  for  integration  and  recommenda- 
tion en  ECPs  received.  The  coordination  of  this  effort  is 
very    difficult    and    is  crucial     to   the   commonality   objective. 
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Written  statements  of  agreement  should  be  developed  to 
implement   this    coordination. 

Analyses  and  tests  will  be  performed  to  isolate  t.h3 
source  of  the  reported  problems.  Problems  related  re  plat- 
form systems  or  within  JSSMO  cognizant  ir?ras  will  be 
examined  in  coordination  with  personnel  and  facili-iss  of 
the  SYSCCMs  and  the  JSSMO,  respectively.  Having  isolated 
the  source  of  the  problem,  alternate  solutions  will  be 
explored  thrcuifh  analysis.  The  approach  taicen  will  be  coor- 
dinated by  the  appropriate  Project  Engineer  with  tasicing 
approval   through  the   CEA. 

The  full  complement  of  CEA,  JSSMO  and  SYSCOM  facili- 
ties will  be  utilized  to  determine  the  best  fix  for  each 
problem.  Solutions  will  be  examined  through  laboratory  and 
platform  tests,  as  reguired .  Test  reports  summarizing  test 
results  and  recommendations  for  implementation  will  be 
prepared. 

New  system  requirements,  technological  issues  and 
ECPs  received  from  PFAs  stemming  from  fleet  utilization,  new 
mission  needs,  =tc.  will  first  be  evaluated  to  determine 
alternative  approaches  to  implsmant  these  capabilities  and 
to  identify  their  impact  on  the  U3  and  other  platform 
systems.  It  is  recognized  as  th^se  inputs  are  evaluated, 
that  the  implementation  integration  of  all  these  new 
requirements  will  require  close  coordination  and  interplay 
with  all  agencies  involved.  This  should  be  handled  through 
a  Preplanned  Product  Improvement  agreement.  The  product  of 
these  efforts  will  be  a  unified  response  and  result  in 
specification  changes,  readiness  improvements,  platform 
integration  packages  or  ECPs.  Each  will  be  accompanied  by  a 
detailed  iirple mentation  plan  which  will  ensure  that  the 
total  program  impact  of  each  change  has  been  accounted  for. 
Where  JSSMO  cognizant  JE  are  involved,  a  coordinated  plan 
will    be    prepared   to    be  sent    to   the  JSSMO.      [Ref.    32] 
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Figure   5,5         ASSESSHEMT   AND    SESPONSE. 

Tc  fulfill  th€  central  managemsnt  function  and  main- 
tain the  Navy  commonality  of  GPS  US,  CSA  must  coordinate  the 
inpuTS   form     the   SYSCCMs   and      the   LFAs.  This    coordina-nion 

will  allow  for  a  unified  response  to  the  Navy  configuration 
Control  Board  (NCCB)  and  ensure  the  commonality  of  the  GPS 
system    is    maintained    within    the   Navy. 
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2-      Nav^  LJILJ  Field   Activities 

The  two  LFAs  for  the  Navy  GPS  program  are  NAVELEX 
LFA       (XLEA)  located      at      th9      Naval        Electronic      Systems 

Engineering  Center,  San  Diego  (NESEC)  and  the  NAVAIP  LFA 
(ALFA)  located  at  the  Naval  Avionics  Center,  Indianapolis, 
Indiana  (NAC).  NESEC  will  perforin  the  cenrral  configuration 
management  funcxion  for  NAVSEA,  which  will  consist  of  all 
shipboard  applications  of  the  GPS  system.  NAC  will  perform 
the  central  configuration  management  function  for  NAVAIR, 
which  will  consist  of  all  airborne  applications  of  the  GPS 
system.      [Ref,    33] 

The  XLFA  and  ALFA  will  provide  engineering  and  t~ch- 
nical      sufpcrr,  perforin      fleet     support        activity       (FSA) 

functions  and  configuration  control  functions  for  both  the 
hardware  and  software  for  their  respective  Navy  unique  US. 
The  management  structure  shown  in  Figure  5.2  indicates  the 
direct  lines  of  communications  that  are  required  to  unify 
the  Navy  configuration  control  effort  and  to  update  and 
support  the  Navy  unique  GPS  hardware  and  software  through 
the    life-cycle    of   the   system. 

An  element  of  the  LFAs  will  be  the  support  integra- 
tion activity  (SIA)  for  the  Navy  GPS  integration  program. 
The  primary  function  of  the  SIA  is  to  provide  follow-on 
engineering  services  during  DT5E  to  support  the  development 
of  the  FMIs  during  Phase  III.  The  LFAs  will  identify  and 
control  the  configuration  (hardware/software)  for  the  GPS  UE 
platform  interface  (FMI) .  this  will  be  a  coordinated  effort 
with    CEA   as   the    pivotal    point   of    intraservice   coordination. 

A  Land  Based  Test  Site  (L3TS)  will  be  established  at 
the  LFAs  to  support  the  GPS  integration  program  and 
software/hardware  changes  through  the  life-cycle  phases  of 
the  GPS  program.  An  extensive  software  repository  including 
firmware,      verification      and   burn-in    functions   for      the   Navy 
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platforms/  GPS  interfaces  and  the  Master  Program  files  for 
the  system  FMIs  will  reside  at  the  LBTS.  [Eef.  3U]  The  LBTS 
will  include  a  software  laboratory  to  perform  the  necessary 
functions   for   processing   software  changes. 

Located  at  both  LFAs,  will  be  a  Configuration  Review 
Board  (CRB)  to  review  and  evaluate  all  changes  to  the  Navy 
GPS  UE  and  assess  the  impact  of  the  changes  in  their  respec- 
tive areas  of  expertise.  A  recommended  composition  of  the 
CRB    is   shewn  in    Figure  5.5.      [Hef.    35] 

The  CRB  has  no  final  approval/disapproval  authority 
for    ECPs.  It    will   review    the      ECPs   and   submit      them    along 

with  their  assessments  and  recommendations  to  the  CEA  for 
evaluation  and  forwarding  to  the  SYSCOM  CCBs  and  the  NCCB 
for    approval/disapproval. 

A  large  task  for  the  LFAs  will  b^  coordination  of 
the  PSSAs;  however  this  must  be  done  to  unify  the  Navy  in  a 
manner  that  will  allow  for  maintaining  commonality  along 
with    an    accurate   product   baseline.  The   Navy   PSSAs   are   the 

field  activities  responsible  for  maintenance  of  systems 
resident  on  platforms  that  are  interfaced  with  the  GPS 
system.  The  PSSA  will  be  responsible  for  conducting  certi- 
fication cf  GPS  configuration  changes  to  ensure 
compatibility  with  interfaced  systems.  The  functions  that 
must    be   performed  by   the   PSSA    are   as    follows:      [Ref.    36] 

1.  Review  and  coordinate  the  analysis  of  all  platform 
problem  reports  and  all  proposed  changes  that  impact 
the   GPS    system   with    the   appropriate    LFA. 

2.  Ensure  that  all  platform  system  problems  and  proposed 
system  changes  related  to  the  GPS  system  are  analyzed 
for  impact  upon  GPS  UE.  Whenever  an  impact  on  GPS  UZ 
is  identified,  the  engineering  data  cf  the  changes 
are  submitted  to,  and  coordinated  with  the  appro- 
oriate  LFA. 


57 


CHfllRnEN 


GPS  LFfl 
SECRETflRIflT 


VEHICLE 

CLASS 

DESK 


UEfl 


•ON 


CLASS 
DESK 


FLEET 
RCP 


LOGISTIC 


TRAINING 


CONTRACTS 


T4E 
REP 


TECIINiCflL 
SERVICES 


OTHERS 


Figure    5.6         CONFIGOBATIOM    3EVIEW    BOARD. 


3. 


4. 


Perfcrm      the    certification      of      GPS      UE  changes      tiiat 
affect  the   interface    characteristics   and    functions   of 
the   related    FMI  unit. 
Participate    en  the  CRBs    as   required. 


58 


Due  to  the  organization  structure  of  the  NAVAIH 
PSSAs  a  major  coordination  problem  exists  for  UAC,  Working 
agreements  should  be  sought  as  soon  as  possible  to  ensure 
that  ALFA  is  established  as  -he  central  and  lead  control 
agency  and  that  the  single  interface  between  ALFA  and  CEA 
is      the  one     that      is  established.  without     this   type     of 

arrangement  the  proliferation  of  different  CIs/C?CIs  between 
NAVAIE  PSSAs  could  result.  This  would  run  counter  to  the 
stated  objective  of  maintaining  commonality  in  the  GPS 
program. 

3.      Navy  Configuration    Control   Board    (NCCB) 

The  NCCB  will  be  responsible  for  the  Navy  UE  configuration 
management      through    the     life-cycle      of      GPS   [Ref.    37],  A 

recommendad  composition  of  the  Navy  Configuration  Control 
Board  (NCCB)  is  shown  m  Figure  5.7.  The  NCCB  will  review 
proposed  ZCPs  and  provide  technical  approval  or  disapproval 
based  on  these  reviews.  It  will  determine  overall  system 
impact  of  the  proposed  change  and  assure  that  the  ECP  covers 
all    subsystems    affected. 

It  is  the  opinion  of  the  reasearcher  that  the  NCCB 
should  be  chartered  with  the  authority  for  final  approval/ 
disapproval  of  all  ECPs  that  affect  Navy  unique  UE  CIs  and 
CPCIs.  Fcr  these  ECEs  an  information  copy  should  be  sent  to 
the  Joint  Configuration  Control  Board  (JCCE)  located  at 
JSSMO  fcr  update  of  the  central  overall  system  configuration 
data    file. 

C.       ECP    FLOW   FOR    Ni7I    UE 

All  proposed  changes  to  the  system  will  be  classified 
with  regard  to  their  total  impact  on  th =  GPS  system, 
existing      documentation,      and      cost    effectiveness.  Change 

classifications    and      justification   codes      will   be      in   acccr- 
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Figure    5-7  NAVY    CONFIGORATION    CONTROL    BOARD. 

dancs  with  DOD-STD-480A  ds  outliaed  m  appendix  C  and  D. 
Proper  classification  ensures  ECPs  vill  be  adequa-^ely 
reviewed.  Class  I  changes  are  further  identified  as  to  A  or 
B  in    accordance    with   the   following:      [Hef.    38] 

1.      CLASS  lA:      A      change    to   the  operational      system    which 

requires    a      conjunctive   system   software      and    hardware 

change. 
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2.  CLASS  13:  A  change  to  the  operational  system  which 
dees  not  require  a  conjunctive  system  software  and 
hardware    change 

Class  lA  and  IB  changes  will  be  assigned  priorities  in 
accordance  with  DOD-STD-48  0A  as  described  in  appendix  E, 
The  priority  assigned  will  be  the  major  factor  determining 
the   time   required  to    fully    process  the   ECP, 

It  is  the  contention  of  the  researchers  that  the  ECPs 
will  mainly  fall  under  the  priority  of  routine  wi-h  a  few 
exceptions  that  will  fall  under  the  argent  priority.  This 
contention  is  based  on  the  researchers  interpretation  of 
Mil-Std-480A  (Appendix  C  through  E)  and  the  operational 
aspects   of      the    GPS      as  a      navigational   aid.  This    can      be 

accomplished  through  the  design  of  the  FMI  and  the  integra- 
tion   of   the   GPS    system  inzo    the    weapon   system    platforms. 

It  fellows  from  the  above  that  if  the  major  portion  of 
the  ECPs  are  routine  then  the  configuration  management 
structure  and  documentation  flow  should  be  designed  around 
the  time  requirements  and  priority  of  the  routine  2CP.  The 
few  Urgent  ECPs  could  be  flagged  and  expedited  en  a  case  by 
case  basis  through  the  system.  A  major  impact  of  routine 
ECPs  would  be  in  the  utilization  of  block  changes.  A  time 
table  could  be  established  for  implementation  of  the  ECPs  as 
one  block  change  (for  example  a  yaarly  basis) .  This  would 
allow  for  the  collection  of  ECPs  and  the  most  effective  use 
of  a  change.  Using  This  method  one  block  change  could  solve 
a  number   cf    problems. 

A  decision  -to  process  ECPs  in  zhis  manner  would  allow 
for  a  stable  production  plan  for  the  contractor  and  a  firm 
planning  horizon  for  the  retrofit  modifications  to  opera- 
tional FMIs.  The  ECP  flow  through  tha  configuration  control 
management    structure    is   depicted   in   Figures   5.8--5.10. 
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?I,    COMPUTER    BASED    MANAGEHEMT    INFORMATION    SYSTEM 

A.       COHPOTER  DATA   BASED    HIS    A    TOOL   FOR    CM 

GPS  presents  a  very  large  problsm  in  the  management 
arena  cf  coordinating  the  various  and  diversified  management 
areas.  The  JSSMO,  as  stated  previously,  is  responsible  for 
the  total  DcD  acquisition/engineering  management  of  the  GPS 
UE   program      after  PMET  in      FY   87.  aasponsibiiites   include 

conf iguraticn  management,  acquisition  logistics,  engi- 
neering, specification,  acquisition,  cataloging, 
provisioning,  maintenance  and  inter-servicing,  spares 
rsquirements,  budgeting  and  funding  management,  financial 
management,  training  and  UE  installation.  The  three 
services;  Navy,  Army  and  Air  Force,  are  responsible  for  the 
above  management  areas  for  the  service  unique  items.  With 
NATO  and  other  agency  use  of  GPS  UE  the  scope  of  the  coordi- 
nation  and   data    management    problems   is   indeed   very   large. 

Coupled  wi-*:h  the  above  is  the  fact  that  there  are  three 
GPS  sets;  single  channel,  dual  channel  and  five  channel, 
that      make      up    the      GPS      UE      family.  These   sets      will     be 

installed  on  various  platforms  bringing  almost  ail  areas  of 
each  service  into  the  coordination  and  data  management 
problem.  Commonality  among  the  different  sets,  which  is 
accomplished  through  the  use  of  common  SRUs  with  common 
CPCIs,  and  the  commonality  within  the  sets  across  various 
platforms  is  a  stated  objective  of  the  GPS  program.  In 
order  to  maintain  this  commonality  and  effectively  manage 
the  GPS  resources  the  managsment  activities  need  to  be 
centralized.  To  support  the  JSSMO,  Navy,  Army  and  Air  Force 
in  centralizing  the  management  activities  and  to  provide  the 
necessary      in-house      engineering      support      for      the      GPS     UE 
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program,  an  on-line  real-time  computer  based  managemsn- 
information  system  (MIS)  is  require!.  This  system  can  then 
provide  the  "TOOL"  to  manage  and  control  the  UE  support 
elements  contributing  to  the  LCC  throughout  the  G?S  program 
life   cycle. 

The  idea  of  a  coihputer  based  information  system  for  the 
configuration  management  of  GPS  UE  is  not  foreign  to  the  GPS 
program-  Lt.  Thomas  atrahamscr.  attended  a  briefing  at  Robins 
AFB  on  25  January  1983  and  Lt.  3erard  Mauer  attended  a 
briefing  at  the  J?0  on  1  February  1983.  Both  briefings  were 
conducted  by  Mr.  John  Fens termachac ,  who  is  the  Navy  Deputy 
System  Manager  and  the  OE  Program  Manager  for  JSSMO,  The 
briefings  dealt  with  the  subject  of  a  computer  based  MIS,  as 
a  tool  for  configuration  management.  Chapter  six  is  devoted 
to  taking  a  look  at  a  computer  based  MIS  that  could  be  used 
as  a  tool  for  management  and  control.  The  observations  and 
conclusions  presented  in  this  chapter  are  based  on  the 
researchers  understanding  and  intarpations  of  the  informa- 
tion   presented    at   the  two  briefings. 

The  coordination  of  the  GFS  UE  program  rolies  heavily  on 
effectively  handling  the  massive  data  requirements  generated 
for  support  of  system  engineering.  The  management  informa- 
tion system  aust  be  centered  around  making  changes  to  a 
design  (i.e.,  SCPs)  and  the  mcnitoring  of  the  impact  of 
these  changes  to  the  product  baseline.  The  biggest  problem 
in  the  past  has  been  the  tracing  of  a  problem  from  genera- 
tion by  the  fleet  or  a  user  activity  through  its  resolution, 
and  all  changes  that  take  place  until  it  comes  cut  the  door 
as   a    mod-kit  to    solve   the   problem. 

An  on-line  real-time  computer  based  MIS  utilizing 
distributive  processing  will  have  as  its  primary  function 
the  support  of  the  centralized  management  activities  by 
identifying,  scheduling,  controlliag,  auditing,  reviewing, 
accounting,      processing   and    inter-relating   a    life   cycle   flow 
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of  the  following  support  data  rala-ced  ro  conrrolling  the  GPS 
DE   baseline: 

1.  ECF    TRACKING    AND    MANAGEMENT   DATA     (the   cen-ral    core) 

2.  INVENTORY/CONPIGOSATION   STATUS    ACCOUNTING    Dhlk 

3.  ITEM    PROCUREMZNT/SUPrORT    DATA 

4.  COMPUTER    RESOURCES    SUPPORT    DATA 

5.  BUDGET/LIFE    CYCLE    SUPPORT    COST    DATA 

6.  LSA    MODELING    SUPPORT    DATA 

7.  PROGRAM    SCHEDULING/PLANNING    DATA 

8.  FLEET   READINESS   MANAGEMENT    DATA 

9.  DISCREPANCY/SERVICE    REPORT    DATA 

10.  MINUTES/ACTION    ITEM    REPORTING    DATA 

The  da-a  base  requirad  to  operate  this  system  would  be  built 
during  the  trarxsition  phase,  which  would  include  rhs  prcducTi 
baseline  and  all  other  contractor  and  test  data.  This  would 
put  the  MIS  fully  operational  at  -he  begining  of  *h3  organic 
support   phase  of  the    GPS   UE    program. 

The  data  base  system  would  be  divided  into  thrae  major 
sections  and  operated  on  a  distributive  bases,  as  shown  in 
Figure   6. 1. 

1.  INFUT/FILE  MAINTENANCE  SECTION:  This  section  is 
ccmpcsed  cf  cn-line  data  antry,  file  maintenance, 
data/  file,  monitoring  of  all  support  data  work  files 
processed/generated  by  the  assigned  support  engi- 
neers, data  entry,  and  data  based  administrators. 
Th=s  data  in  this  section  is  in  a  changing  mode  and 
provides    a   mirror   image   of   the    master    data    base. 

2.  INQUIRY  DATA  BASE  INFORMATION  MIA^ZMENT  SECTION: 
This  section  is  composed  of  the  master  data  basss 
retaining  current  support  data  information  generated 
from  the  work  files.  This  section  is  used  primarily 
as  a  management  tool  for  data  base  administrators, 
and  program  managers  as  an  on-line  inquiry/ 
information  management  system.  This  is  an 
interactive    system  wi-^h   only   read   data. 
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Figure   6.1         SECTION    OVEBVIEW. 

3-       ADMINISTRATIVE    SECTION:       This    section    is    composed    of: 
5.)    Simplified    inrar- of  f  ice   word   processing    system   for 
office   letters,    memos,    and    e-cc. 

b)  Document  word  processing  system  for  larg*  docu- 
ments requiring  independent  controlling  of 
document    data. 

c)  Graphics  section  for  gensrating  management  graphic 
illusx rations    for    scheduling,    planning,    and   etc. 

The  mcdern  day  computer  puts  the  capability  of  such  a 
MIS  at  our  disposal.  The  major  item  will  be  the  development 
and  maintenance  of  rhe  software  to  opera-e  a  real  zime 
interactive,  distributive  data  based  processing  system.  The 
existence   of  cross    country    telecommunication    networks   allows 
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for  the  centralization  of  this  systea  at  the  JSSMC,  with 
remote  terminals  and  time  sharing  capabilities  for  th^ 
respective   Services      and   agencies.  Thus;      the      technology 

exists  for  rha  utilization  of  this  configuration  management 
tool. 

B.       MIS    AND    THE    ECP 

The  inter-activity  of  the  data  bases  will  allow  manage- 
ment to  us r  "WHAT  IF"  drills  in  determining  and  reviewing 
solutions  to  SPS  UE  problems.  Proposed  SCP  solutions  can  be 
input  and  an  impact  study  can  be  accomplished  on  a  real  time 
basis,  along  with  a  LSA  in  accordance  with  MIL-STD-1338-1. 
Therefore;  when  a  solution  is  generated  the  inventory, 
support  and  LCC  impacts  can  be  readily  obtained  prior  to 
putting  the  solution  into  effect.  This  would  allow  the  use 
of  an  iterative  prccess  to  determine  the  best  solution 
considering  trade-offs  to  the  problem.  With  the  GPS  sets 
being  80^  software  the  traclcing  of  software  changes  can  be 
accomplished,  along  with  the  impact  study  of  each  software 
change.  When  a  computer  program  change  is  required  the 
system  identifies  that  change  to  the  new  CPCI.  The  software 
change  is  then  linked  to  the  firmware  part  number  (chip)  , 
which  is  further  linked  to  the  S RU  that  chip  is  on. 
Therefore;  management  would  know  the  SRU  effected  the  chip 
and      the   computer      programs    that      are   on      that   chip.  This 

becomes  especially  important  when  dealing  with  interface 
compatability  between   DoD  common    and    Service    unique. 

Each     ECP  generates     a    record      for      the   problem.  This 

record  remains  active  until  the  iZ?  is  closed  out  with  a 
mod- kit    installation.  The   record      is    kept      for    historical 

data.  Working  on  the  concept  of  block  changes  this  aspect 
allows  iLanagement  tc  monitor  the  changes  and  effectively 
coordinate     them   into     a      block      change.        This      provides      a 
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complete  status  tracking  of  each  SCP  throughout  its  review 
process  and  couples  with  the  ECP  rhs  impact  review  of  that 
change.  Cutting  across  the  ECPs  allows  for  establishing  the 
budgeting  information  required  for  the  purchase  and  imple- 
mentation of  the  block  change.  In  order  to  keep  the  ECPs  on 
schedule  a  comm  log  system  would  let  each  activity  knew  if 
there  is  an  action  item  for  them  in  the  system.  Coupled 
with  this  a  PERT  network  would  show  each  activities  review 
response   date. 

The  computer  based  MIS  would  combine  the  inventory  and 
configuration  management  system  to  accomplish  asset 
accounting  not  only  for  DoD,  but  for  each  of  the  services. 
This  system  has  the  capability  of  telling  aanagement  what 
the  asset  is,  where  it  is  located,  its  condition  and  compat- 
ability.  Each      platform      creates    a      separate      record      for 

tracking  the  location  of  the  LHUs  a.id  the  SRUs,  This  allows 
also    for   the  system    to  show    the   impact   by    platform. 

C.       MIS    POTENTIAL   PRCELEMS 

The  system  discussed  sc  far  seems  to  be  the  dream  tool 
for  configuration  control  management  of  the  GPS  UE. 
However;  certain  areas  appear  to  the  researchers  as  poten- 
tial   problems  requiring   farther   research, 

'' •  R^l^  Security :  The  system  to  operate  completely  and 
effectively  will  require  priviledged  data  and 
possibly  classified  data  on  file  or  accessable 
through    other    computer   systems.  Without    the    proper 

data  security  contractors  could  obtain  priviledged 
data  allowing  them  an  unfair  advantage  in  future  GPS 
related  contracts,  and  classified  data  could  fall 
into  the  hands  of  the  wrong  people.  What  security 
measures  can  be  taken  to  ensure  only  the  people  with 
the   need    and   clearance   can   access   this   data?      The   use 
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cf  user  identificari on  codes  and  special  codsd  fil^s 
does   not    seem   to   fully    answer    this    question, 

2»      Quality      Assurance      of    In p ut      Data:  The      potential 

problem  is  expressed  by  the  old  saying  of  garbage  in 
garbage    cut.  The    system     can   provide     some    qualify 

assurance  through  the  use  of  data  cross  checking, 
this  would  eliminate  the  pos3ibilix.y  of  inputting 
incorrect  part  numbers,  NSNs,  or  ECP  numbers  and  etc. 
into  th a  dara  base.  The  use  of  designated  data  base 
managers  -co  review  all  inputs  from  each  ac*ivi-y, 
will  also  provide  some  quali-y  assurance.  However; 
will  this  provide  enough  qualify  assurance  to  ensure 
an   accurate    up-to-date   data  base? 

3»  Hardware  Obsolescence:  Advances  that  are  being  made 
in  ccmpuxer  technology,  brings  the  hardware  obsoles- 
cence problem  into  view.  A  possible  solution  to  this 
problem  would  be  for  the  governmen"  to  purchase  only 
the  data  based  system  software  and  lease  the  required 
hardware.  This   not      only      eliminates  the      hardware 

obsolesence  problem  but  will  also  spread  the  cost  of 
the  hardware  over  more  years.  Centrally  locating  the 
computer  system  at  the  JSSMO  with  remote  terminals  on 
a  time  sharing  basis,  the  problem  of  the  diffusion  of 
configuration  management  system  software  would  be 
curtailed.  The  major  question  that  must  be  answersd 
in  this  area  is  does  the  benefit  outweigh  the  cost  of 
such   a  system? 

^'      Configuration   Control      of    Data      Base   Software;  The 

configuration  control  of  the  data  base  MIS  software 
presents  another  potential  problem.  A  configuration 
control  board  with  members  from  each  of  the  user 
communities  would  ne^d  to  be  established  to  review 
and  coordinate  changes  required  in  the  MIS  software. 
Designing   the      MIS   software  in      a   modular      format    and 
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using  high-level  computer  language  will  allow  ^he 
necessary  changes  to  be  made  in  an  efficient  manner. 
The  qusstion  still  remains  abom:  who  will  chair  such 
a  board  and  who  will  make  t,he  final  decision  on  the 
changes. 
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VII.    SUHMASY 

A.       ANALYSIS  OF    THE    OVERALL    SYSTEM 

As  suat€d  earlier,  the  primary  Dbjacxive,  of  The  thesis, 
was  to  freeze  the  dynamic  nature  of  the  configuration 
management  plans  and  examine  ths  configuration  control 
aspects  of  the  plans.  The  risk  x.hat  is  taken  by  doing  -his 
is  nhe  implication  that  the  configuration  control  management 
plans  exist  and  will  continue  to  exisr  as  they  are  seen  ar 
this  one  point  in  time.  The  realistic  pic-ure  is  that  ever- 
ything is  continually  changing  and  these  changes  will  impac: 
configuration  control.  What  freezing  -he  plans  in  time  does 
is  to  allow  the  researchers  the  opportunity  to  examine  i- 
and  present  a  point  estimate  for  comparison.  Therefore,  -he 
problems  and  conclusions  reflect  the  configuration  con-rol 
management    plans   at    this   point    in   time. 

The  configuration  control  management,  plans  for  the  DoD 
common  and  the  Navy  unique  CIs  and  CPCIs  have  all  the 
required  and  necessary  pieces  to  allow  it  ro  evolve  into  an 
effective  and  feasible  plan  for  configuration  control  during 
organic  support.  The  conception  and  plans  to  incorporate  a 
computer  based  MIS  as  a  configuration  management  tool  shews 
perceptive  insight  into  the  importance  and  complexity  of 
configuration  control  management  for  GPS  UE.  This  tool  also 
offers  the  ability  to  integrate  nor  only  configuration 
management  among  the  different  services,  but  also  inventory 
and  logistics  support,  which  is  necessary  to  provide  a 
control  system  that  will  monitor  the  GPS  UE  in  an  efficient 
and    effective  manner. 
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To  arrive  at  the  overall  conclasion  that  the  configura- 
tion control  management  plans  are  managerialiy  sound,  z.'aa 
researchers  looked  for  items  that  they  fel-  were  crucial. 
The    first      item    was      the    baseline      management   concept.  We 

found  that  a  functional  baseline  existed  m  phase  1  and  an 
allocated  baseline  exists  during  phase  2.  Work  is  in 
progress  to  establish  a  product  baseline  for  phase  3  and 
configuration  control  management  plans  will  use  the  product 
baseline   as   its    basis. 

The  researchers  arrived  at  the  conclusion  that  the 
management  plans  acknowledged  the  differencs  between  hard- 
ware and  software  configuration  control.  The  necessary 
support  documentation  and  facilitiss  for  software  configura- 
tion control  were  in  the  plans.  The  positive  point  here  was 
that  software  changes  were  not  looked  on  as  maintenance,  but 
were  considered  as  design  changes.  The  software  concept  is 
very  important  due  to  the  fact  that  the  GPS  UE  is  apprcxia- 
mately  80^  software  and  this  is  the  area  seen  as  having  the 
greatest  potential  for  change.  Thus,  a  majority  of  the 
costs  associated  with  change  proposals  will  result  from 
software   changes. 

The  ether  critical  item  was  the  management  structure 
itself.  The  plans  acknowledged  the  need  for  centralized 
management  of  configuration  control  to  meet  the  objective  of 
commonality.  The  researchers  understood  the  plans  to  place 
the  JSSMC  as  the  central  manager  of  DoD  common  UE  and  CEA  as 
the  central  technical  manager  of  Navy  unique  OE.  The  large 
number  of  agencies  and  platforms  involved  in  the  GPS  program 
requires  a  centralized  management  structure.  The  Navy  and 
the  JSSMC  have  developed  plans  for  the  management  structure 
that  places  control  boards  at  the  proper  level  to  ensure 
regulation   of  the  UE   configuration. 
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The  above  elements  lead  the  researchers  to  th-e  cor.cla- 
sion  that  the  prescribed  configuration  control  management 
plans  for  GPS  UE  were  sound.  These  elemen-s  are  only  the 
start  of  a  good  configuration  control  program  and  on  their 
own  will  not  evolve  into  an  effective  and  feasible  configu- 
ration ccntrol  management  system.  Configuration  control  is 
not  a  fully  automatic  tool,  it  cannot  be  installed, 
programmed,  switched  on  and  left  to  run  by  itself.  Like 
most  tools,  it  will  perform  well  only  when  used  with  skill, 
conscience,    discretion  and    energy. 

B.  MAJOR    PBOBLEM 

The  major  problem  in  the  opinion  of  the  researchers  was 
that  the  different  elements  for  configuration  control  were 
not  integrated.  In  order  to  continue  forward  and  develop 
the  plans  into  a  working  solution  we  feel  thax  written 
agreements  of  understanding  must  be  developed  and  agreed 
upon    by      the  major   agencies.  These   agreements      could  then 

ensure  -chat  every  agency  was  moving  in  xhe  same  direction  in 
develcping  their  plans  for  configuration  control  management. 
If  the  agencies  are  allowed  to  continue  in  an  undirected 
environment,  concerning  configuration  conxrol,  the  objective 
of  commonaiiry  will  be  lost  not  only  in  Service  unique 
items,    but   also    in    rhe  DoD    common   items. 

C.  RECOMMENDATIONS 

Management  attention  must  be  focused  on  the  development 
of  written  statements  of  agreemem:.  These  statements  are 
required  to  establish  the  parameters  and  boundaries  needed 
by  the  user  agencies  to  bring  their  configuration  control 
and    integration    management    plans   to    maturity. 
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The  following  are  r  ecD  maiendations  -hat  -the  researchers 
through  their  analysis  have  determined  to  be  crucial  to  the 
GPS  UE  configuration  control  managemen-  plans.  The  list  is 
not  all  inclusive,  but  represents  a  start,  that  we  consider 
is  in  the  right  direction,  for  the  evolution  of  zhe  GFS  UE 
configuration  control  plans  into  an  efficient  and  effective 
configuration  control   system, 

'^  •      Agency    Boundary   Agreements 

A  statement  cf  agreement  should  be  developed  that 
precisely  identifies  the  boundaries  for  each  agencys'  area 
of  responsibility  and  authority.  An  example  would  be  to 
identify  the  boundary  concerning  changes  affecting  the 
interface      between   the     RPU    and      the    F?1I.  The    Navy,        for 

instance,  would  be  limited  to  changes  affecting  host  vehicle 
unique  FMIs.  Any  recommended  changes  to  the  FMI  that  affect 
the  RFU  wculd  be  out-side  the  Navy's  boundary  and  would  fall 
under  JSSMO  jurisdiction.  What  we  mean  is  that  no  problem 
or  enhancement  cf  the  host  vehicle  or  service  uniqua  FMI 
should  be  allowed  to  ripple  back  through  the  HPU.  Without 
this  limit  specifically  identified,  each  service  could 
theoretically  make  changes  to  their  respective  FMIs  that 
also    alter     the    respective    RPD   capabilities.  The    ultimate 

result  wculd  be  a  significant  loss  in  commonality  and  an 
increase   in   the    complexity    of   configuration  control. 

We      recommend  that      any      discrepancies  or      conflicts 
that      affect     interservice      boundary      responsibilities      (for 
example,        conflicts    between      ths   Navy      and      the   Air      Force) 
should   bfi      handled    by  the      JPO    prior      to   PMRT   and      the    JSSMO 
after      PMRT.  Intraservice      boundary      disputes      should     be 

handled  by  their  respective  QE  central  management  office, 
such  as  the  CEA  in  the  Navy.  This  would  eliminate  confusion 
between  and  within  the  Services  concerning  GPS  UE  boun- 
daries. Providing      specific      keystone      agencies      in      each 
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service  re  monitor  and  make  decisions  on  the  UE  configura- 
tion control  boundaries  would  help  facilitate  configuration 
control   management. 

2«      Centralized    Management   Agreements 

The  key  to  configuration  control  management  is  a 
centralized  management  structure.  All  DcD  ccmmon  UE  will 
fall  under  the  central  management  of  the  J3SM0.  The  Navy 
central  technical  management  should  be  placed  at  C2A  with 
NAC  representing  the  NAVATR  platforms  and  NESEC  San  Diego 
representing  rhe  NAVSEA  platforms.  This  type  of  a  manage- 
ment structure  is  essential  in  mainraining  the  commonality 
objective  and  should  be  stated  in  writing  as  a  statement  of 
agreement  between  the  Naval  SYSCDMs,  CSA  and  the  LFAs. 
Without  a  statement  of  agreement,  coordination  will  be 
almost  impossible.  The  coordination  at  this  level  is  very 
important  in  aaintaining  control  of  the  ECPs  and  obtaining 
the    ccmmcnality    objective. 

3»      GPS    Inteqr  at  ion    Agreements 

A  firm  integration  plan  for  the  Navy  is  needed 
immediately  to  allow  the  configuration  control  plans  to 
evolve      into  a      workable     system.  An    integration      concept 

statement  of  agreement  should  be  developed.  G?S  is  a  navi- 
gational aid  that  can  provide  tr*e  host  vehicle  with  very 
accurate  position,  velocity  and  time,  '^hat  ws  mean  by  a 
navigational  aid  only  can  be  seen  best  by  an  example.  The 
example  we  will  use  is  the  integration  of  G?S  into  a  high 
performance   aircraft      with    an      INS   system.  The    S?S      would 

interface  only  with  the  INS  and  act  as  an  inflight  cali- 
brator for  the  INS.  Thus;  the  GPS  data  is  fed  to  the  INS 
and  the  INS  in  turn  interfaces  the  rest  of  the  sensors, 
which  it  already  does.  This  type  of  integration  would  allow 
for    simplification      of  the    design    (mainly      software),      limit 
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intagraticn  problems  and  still  utilize  the  highly  accurate 
position,  velocity  and  time  data  of  GPS.  This  should  b<r  ^.he 
strategy  followed  for  integration.  GPS  should  be  ussd  as 
the  basic  navigation  aid  among  user  platforms  and  electroni- 
cally tied  into  the  present  host  vehicles  navigation  systems 
to   permit   continuous    updating   of   the    navigational    plot. 

The  concept  of  integrating  GPS  into  numerous  sensors 
and  feeding  data  back  and  forth  has  created  the  effect  of 
increasing  the  complexity  of  the  design  and  configuration 
management.  In  order  to  develop  a  cohesive  integration  plan 
top  down  management  direction  is  required.  pflE- 106-2  deci- 
sions for  the  Navy,  with  J?0  concurrence,  via  CEA  and 
through  the  LFAs  should  be  made  at  this  time  to  produce  the 
necessary  guidelines  for  the  Navy  platform  managers,  who 
must  be  the  integration  planners  for  their  respective  plat- 
forms. We  feel  that  a  decision  to  integrate  GPS  as  a 
navigational  aid  only  and  not  as  a  "do  everything"  system 
would  allow  for  effective  integration  plans.  Preplanned 
product  improvement  would  be  used  to  allow  for  future  expan- 
sion and  integration  of  the  GPS  system  into  updates  of 
present  weapon  systems  and  subsequent  new  platforms.  'We  see 
this  as  a  natural  extension  of  the  GPS  utilization  after  the 
initial  system  integration  problems  are  resolved  and  its 
full    capabilities  are  understood    by    the   user   agencies. 

^«      1££   Tracking    Agreements    (During   Testing) 

Management  attention  needs  to  be  focused  on  devel- 
oping a  system  to  track  and  monitor  all  changes  during  the 
testing  of  the  GPS  OE.  This  requires  a  statement  of  agree- 
ment between  the  contractors  and  the  J?0  that  states  exactly 
how  the  changes  will  be  tracked  and  monitored  during  DT5E 
and  ICT5E.  If  these  changes  ?ire  not  tracked  and  monitored, 
the  required  product  baseline  for  configuration  control  will 
not    be      available  at      the   end   of      the   testing      period.        The 
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major  picblsm  exists  during  the  overlap  of  DT&S  =r.d  OTSE. 
Needless  to  say,  without  this  product  baseline  there  can  be 
no   effective  configuration    control  management, 

5-      Routine    Block   Change   Agreements 

An  agreement  should  be  developed,  among  ail  the 
involved  agencies,  tha-  adopts  the  block  change  concept  and 
establishes  a  time  table  for  block  change  implementation. 
Integrating  the  GPS  UE  into  the  weapon  system  platforms  as  a 
navigational  aid  should  result  in  the  majority  of  the  ECPs 
being  routine  priority.  This  would  reduce  the  amount  of 
contract  negotiation  required  to  implement  the  changes 
during  production  and  allow  for  scheduled  planning  of 
retrofit  modifications  to  the  UE  in  operation.  If  this 
statement  is  not  developed  and  accepted  the  control  and 
timing  of  ECPs  will  be  seriously  effected.  Thus,  creating 
the  need  for  a  more  complex  configuration  control  management 
system,    which  will    escalate   the  system's   operating   costs. 

6 •      Nsv V  Software  Laboratory    Agreements 

A  written  statement  of  agreement  should  be  developed 
among  the  three  Navy  Software  Laboratories,  This  agreement 
should  define  each  laboratory's  area  of  responsibility  and 
its  interface  with  the  other  laboratories.  As  stated  in 
chapter  five  the  two  software  laboratories  at  the  LFAs  could 
be  -iliminated  with  the  use  of  a  "dumb"  FMI,  However,  it  is 
the  opinion  of  the  researchers  that  to  maximize  commonality 
and  to  give  the  FMI  the  ability  to  effectively  utilize  and 
incorporate  preplanned  product  improvement  a  FMI  that  lies 
between  the  two  extremes  would  be  optimal.  This  results  in 
the    need   for  software  laboratories   at   CEA,    ALFA    and    XLFA, 

The  agreement  should  establish  the  CEA  laboratory  as 
the  Central  technical  managemer,t  point,  suplemented  by  the 
LFA    laboratories.  Without   this      agreement   duplication     of 
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effort,  increased  development  time  and  increased  cost  wcuid 
occur   with   software    ECPs. 

7 •      U E   Sets    Procurement 

The  configuration  control  management  plans  tend  to 
reflect  the  degree  cf  complexity  found  in  -he  GPS  system. 
We  feel  that  the  selection  of  a  3  set  UE  family,  with  the 
objective  of  maximizing  commonality  in  all  three  sets  have 
caused     the     management    plans      undue      complexity.  Further 

research  is  required  to  support  th=  plan  of  purchasing  the 
single  channel  and  five  channel  sets  only.  We  feel  that 
along  with  this  research  the  concept  of  dropping  the  common- 
ality objective  between  the  two  sets  should  also  be 
considered.  This  would  eliminate  some  of  the  configuration 
management  complexity  and  could  also  free  the  design  for 
more      efficient    operation.  This      would      also   provide      the 

opportunity  for  the  selection  of  two  contractors,  one  for 
single     channel      and      the      othar   for      the      5    channel.  The 

overall  benefits  would  be  an  increase  in  the  technological 
base    and    production    capabilities   of   the   GPS   system. 
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APPENDIX    A 
ABBREVIATIONS 

Air   Fcrcs 

Air    Fores  Logistics   Command 
Air    Pcrc<=!   Regulation 
Air    Force  Systams   Command 
Air    Force   Syst.sms   Command/Space    Division 
Air    Logistics   Cenrsr 
Navair  Lead    Field   Activi-y 
Airframe   Platform   Integration 
Applied   Physics   Laboratory 
C/A   CODE    Course/Acqaistion   Signal 

Configuration   Control    Board 

Configuration   Conrrol   Board  Directive 

Configuration   Control    Board   Raquesx 

Contract    Date   Requirements   List 

Control/Display   Unit 

Central   Engineering    Activity 

Configuration   Item 

Configuration    Management 

Configuration    Management   Plan 

Configuration    Management    System 

Computer   Program   Control   Item 

Computer   Program   Configuration   Sub-Beard 

Computer   Program   Identification    Number 

Computer   Program   Screening   Panel 

Configurtion   Review   Board 

Computer   Resources   Integrated   Support    Plan 

Controlled    Reception    Pattern    Antenna 

Control   Segment 

Configuration    Sub   Board 
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1. 

AF 

2. 

AFLC 

3. 

AFR 

4. 

AFSC 

5. 

AFSC/SD 

6. 

ALC 

7. 

ALFA 

8. 

AFI 

9. 

APL 

10. 

C/A  COD 

11. 

CCB 

12. 

CCED 

13. 

CCBR 

14. 

CERL 

15. 

CDU 

16. 

CFA 

17. 

CI 

18. 

CM 

19. 

CMP 

20. 

CMS 

21. 

CPCI 

22. 

CPCSE 

23. 

CPIN 

24. 

CPSP 

25. 

CRB 

26. 

CRISP 

27. 

CRPA 

28. 

CS 

29. 

CSE 

30.  CSCCB  Control   Sagmsn-   Configuration   Control   3cari 

31.  DMA  Defense  Mapping   Agency 

32.  DOD  Department    of   Defense 

33.  DSARC  Defense   Systems   Acquisition  Review   Council 

34.  DTSE  Development    Test    and    Evaluation 

35.  ECE  Engineering    Change  Proposal 

36.  ECR  Embedded   Computer   Rsscurces 

37.  ECS  Embedded   Computer   System 

38.  EPEOM  Electronically   Progammabls    Read   Only   Memory 

39.  FCA  Func-ional    Configuration   Audi- 

40.  FMI  Flexible    Modular   Interface 

41.  FCC  Final  Operational  Configuration 

42.  FRPA  Fixed   Reception   Pattern    Antenna 

43.  FSA  Field  Support    Activity 

44.  FY  Fiscal  Year 

45.  GFS  Global  Positioning  System 

46.  lAW  In    Accordance    With 

47.  ILS  Integrated   Logistic   Suppcrt 

48.  ILSP  Integrated    Logistic   Support   Plan 

49.  INS  Inerticil   Navigation   System 

50.  I/O  Input/Output 

51.  I0T5E  Initial  Operational   Test    and   Evaluation 

52.  ISF  Integration    Support    Facility 

53.  IV&V  Independent    Verification   and   Validation 

54.  JCCB  Joint  Configuration   Control   Board 

55.  JPC  Joint   Program   Offica 

56.  JSSM  Joint  Service    System    Manager 

57.  JSSMO  Joint   Service    System    Management   Office 

58.  JSSMP  Joint  Service    System    Management    Plan 

59.  LHTS  Land    Eased    Test   Site 

60.  LCC  Life    Cycle    Cost 

61.  LFA  Lead    Field    Activity 

62.  LRU  Line    Replaceable   Unit 

63.  LSA  Logistic   Support   Analysis 


81 


64. 

MCS 

65. 

MIL    STD 

66. 

MIS 

67. 

NAC 

68. 

NATO 

69. 

NAVAIR 

70. 

NAVELEX 

71. 

NAVSEA 

72. 

NCCB 

73. 

NSSSC 

74. 

0?fi 

75. 

OSD 

76. 

0T5E 

77. 

P    Ccd9 

78. 

PCA 

79. 

PCV 

30. 

PFA 

81. 

PM 

82. 

PrtE 

83. 

PKR 

84. 

PMRT 

85. 

P0S/51AV 

86. 

PSE 

37. 

?SSA 

88. 

RFI 

89. 

RPO 

90, 

SAC 

91. 

3D 

92. 

SESA 

93. 

SIA 

94. 

SM 

95. 

SPI 

96. 

SHU 

97. 

SSCCB 

Master  Control   Staticn 

Military   Standard 

Managsment    Information   System 

Naval  Avionics  Center 

North   Atlantic  Treaty   Organization 

Naval  Air  Systems   Command 

Naval  Electronic   Systems   Command 

Naval   Sea   Systems  Command 

Naval  Configuration  Control   Board 

Naval  Electronic   Systems    Engineering   Center 

Office  of  Primary   Responsibility 

Office  of  the    Secretary   of   Defense 

Operational    Test    and    Evaluation 

Precise    Navigation  Signal 

Physical   Configuration   Audit 

Physical   Configuration   Verification 

Participating   Field   Activity 

Program   Manager 

Project   Manager,    Electronics 

Program   Management   Responsibility 

Program   Management   Responsibility   Transfer 

Positioning    and    Navigation 

Peculiar   Support    Equipment 

Platform   System   Support    Activity 

Radio   Frequency    Interference 

Reciever   Processor  Unit 

Strategic  Air   Command 

Space  Division 

Ships   Fl aet    Support    Activity 

Support  Integration    Activity 

System  Manager 

Ships  Platform   Integration 

Shop    Replaceable   Unit 

Space  Segment   Configuration   Control    Board 
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98.  SSO 

99.  TWG 

100.  UE 

101.  USA 

102.  USAF 
10  3.     OSN 

loa.    vsv 

105.  WB-ALC 

106.  XLFA 


System  Support   Office 
Transfer   Working   Group 

User  Equipment 

United  States   Army 

United   States   Air  Force 

United   States   Navy 

Verificationa    and   Validation 

Warner    Robins    Air  Logistics   Cen-e: 

Navelex   Lead   Field    Activity 
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APPENDIX    B 
DEFINITIONS 

1.  BASELINES :  A  configuration  identification  document 
or  set  of  such  documenrs  (including,  for  example, 
computer  program  listings,  tapes,  card  decks,  etc.) 
fcrmally  designated  and  fixed  at  a  specific  time 
during  a  program's  life  cycle.  Baselines,  plus 
approved  changes  to  baselines,  constitue  the  curren-c 
configuration  identification.  There  are  three 
distinc-  configuration  baselines;  once  established, 
they  are  maintained  and  controlled  throughout  -he 
life-cycle  of  the  item  as  the  following  separate 
baselines  : 

a)    FUNCTIONAL      BASELINE;  The      formally      designated 

functional  configuration  identification  fixed  as  a 
product  of  the  initial  or  concept  exploration 
phase    of   the  acguisition  cycle. 

D)  ALLOCATED  BASELINE;  The  formally  designated  allo- 
cated configuration  identification  fixed  as  a 
product  of  the  demonstration  and  validation  phase 
of  the  acquisition   cycle. 

c)  PRODUCT  BASELINE;  The  formally  designated  product 
configuration  identification  fixed  as  a  result  of 
incremental  completion  of  the  configuration 
audits,  during  the  full-scale  development  phase  or 
as  a  result  of  the  completion  of  the  configuration 
audits  as  single  events  and  a  final  product  of  the 
full-scale  development  phase  of  the  acquisition 
cycle. 

2.  COMPUTER    PROGRAM:      A    series   of    instructions    or   state- 
ments in    a    form  acceptable  to    an    electronic    computer. 
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which  2.re  designed  to  cause  the  computer  to  •sxecuta 
an   operation    cr  series  of   operations. 

CC MFUTER       PRQGR&M      CONFIGOEATION         ITEM       (CPCI)  :  A 

ccmputer  program  that  is  designated  by  -he  customer 
for  configuration  managemenz  and  control. 
CCMTUTER  FROG  BAM  DOCUMENT A TI3N  PACKAGE:  An  aggraga- 
-icn  of  all  program  documentation  thaz  is  required  in 
the  development  of,  or  testing  of,  a  specific 
computer  program;  i.e.,  flow  charts,  sysxems  specifi- 
cations I  and  II,  engineering  data  (design  test, 
interface  specifications,  etc.)  source  listings  and 
scurce  prcgrairs,  programmers  notebook,  and  like  data. 
COMPUTER      OPERATIONAL    PROGRAMS;  Computer      programs 

required  to  operate  a  syststn.  These  programs  are 
lcad=d  in,  and  run  in  the  computer  equipment  during 
system        operation;  i.e.,  Executive/Supervisor, 

Functional/Application,  Input/Ou-put,         and        like 

programs. 

CCMPUTER  REFERENCE  MANi^L:  Manuals  related  to  the 
use  of  computer  hardware  cr  installation  of  computer 
hardware;  i.e.,  manuals  containing  instructions  cr 
general  information  for  the  operational  checkout  or 
maintenance    of  computer  hardwara. 

COMPUTER  SUPPORT  PROGRAMS :  Computer  programs  gener- 
ally used  for  the  development  and  maintenance  of 
other  computer  programs.  Support  programs  include 
operating      systems,         assemblers,  compilers,        and 

leaders. 

CCMPUTER  TEST  PROGRAMS:  Computer  programs  developed 
to  analyze  or  test  systems  and  component  performance. 
These  programs  include  maintenance  and  diagnostic 
programs  to  analyze  performance  and  to  detect  or 
isclate    faults   in   computer  equipment. 
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9«  CCMPUTER  RESOUECES:  The  torality  of  comput-ir  =qaip- 
msnt/  computer  programs,  associared  data  and  documer.- 
tation,    r'rlated  supplies,    services    and   personnel. 

10.  CCNFIGU RATION  MANAGEMENT;  A  discipline  applying 
technical  and  administrative  direction  and  surveil- 
lance to  (1)  identify  and  document  the  functional  and 
physical  characteristics  of  a  configuration  item,  (2) 
ccnxrol  changes  to  these  characteristics,  and  (3) 
record  and  report  change  processing  and  the  implemen- 
tation status    of   each   change. 

11.  CONFIGURATION  STATUS  ACCOUNTING:  The  recording  and 
reporting  of  an  approved  configuration  identifica- 
tion, and  the  status  cf  proposed  changes  to  the 
approved  configuration  and  the  implementation  status 
of   approved    changes. 

12.  CONTROL  SOFTWARE :  Common  to  a  computer  type  and 
required  to  execute  a  computer  program,  but  it  does 
not  contain  the  specific  application  instructions, 
data    or    logic. 

13.  DEFICIENCY; 

^)  Design  Deficiency ;  Any  condition  that  limits  or 
prevents  the  use  of  material  for  the  purpose 
intended  or  required  where  the  material  meets  all 
other  specifications  or  contractual  requirements. 
These  deficiencies  cannot  be  corrected  except 
through  a    design    change. 

^)    Quality        Deficiency;  Any        deficiency         (e.g., 

physical,  chemical,  electrical,  functional)  noted 
in  material  which  is  attributable  to  nonconfor- 
mance to  applicable  specifications,  drawings, 
standards,  or  technical  orders,  or  workmanship 
during  manufacture,  repair,  modification,  or 
maintenance. 
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c)    Computsr      Program    Deficisncy:  An      arror    in      the 

statements  cr  instructions  thai  make  up  a  ccmcuTer 
program  used  by  an  embedded  computer  system.  The 
deficiency  may  consist  of  syntax,  logic,  cr  ether 
discrepancies  that  causa  tha  program  to  fail  the 
intended    function, 

14.  EMBEDDED  CO  MP  PIER  SYSTEM;  A  computer  (or  computers), 
equipment,  documentation,  and  programs  that  are 
integral  to  a  weapon  system,  subsystem,  cr  support 
system  whose  primary  purpose  is  to  control,  s^nse, 
interpret,  process,  aid  in,  or  direct  operation  of 
the   larger  system. 

15.  FIRMWARE;  Software  embedded  in  special  media  and 
cannot  be  readily  modified  under  program  control; 
that  is,  "read  only."  It  can  be  modified  only  by 
special  processes  which  provide  physical  and/or  elec- 
tronic access  to  the  media.  Examples  are  read  only 
memory  (ROM),  programmable  read  only  memory  (P80M)  , 
elactrically  alterable  read  only  memory  (EAROM)  ,  and 
erasable    programmable   read   only  memory    (EPROM)  . 

16.  H A 5 D W AR E  INTENSIVE;  Those  microprocessor  applica- 
tions in  which  the  function  is  fixed  and  application 
software/firmware  is  not  expected  to  change;  or  would 
require  redevelopment  of  the  application  function 
itself  if  a    change   is  necessary. 

17.  INTEGRATION  SUPPORT  FACILITY;  An  engineering 
facility  established  to  support  weapon  system 
embedded  computer  systems.  It  is  made  up  of  people, 
equipment,  physical  and  anvironmental  facilities, 
data,  documentation,  and  procedures.  Its  uses  may 
include  the  capability  to  simulate  missions,  evaluate 
ccmputerized  systems  or  subsystems,  test  modifica- 
tions,  and  integrate  hardware,  software  and 
man-iachine    interfaces.      It   provides   a   capability    for 
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fcase   line     and  configuration      managemenu   of      software 
configured  items. 

18.  INISRFRCE:  A  region  common  to  two  or  more  elements, 
systems,  projects,  cr  programs,  charac-erized  by 
mutual  physical,  functional,  and/or  procedural  prop- 
erties. 

19.  MICH CCO^PUT EH :  A  complete  electronic  computer  on  a 
single  integrated   circuit. 

20.  MICRCCDMPUTER  BOARD;  A  small  number  of  integrated 
circuits  on  a  board  to  form  a  complete  elec-ronic 
computer. 

21.  MICRCCOMPOTER  CHIP  SET:  A  small  number  of  integrated 
circuits  that  together  form  a  complete  electronic 
computer. 

22.  iUCROPROGRAM  FIRi'lWARE;  Firmware  at  the  microcode 
level;  that  is,  ROa-based  programs  that  identify  the 
instruction    set  of  a    particular    machine. 

23.  MICRC PROCESSOR:  A  single  integrated  circuit  which 
determines  and  carries  out  the  instruction  architec- 
ture of    a  particular    computer. 

24.  MICROPROCESSOR  FAMILY:  A  collection  of  integrated 
circuits  which  includes  microprocessors  and  the 
support  products  necessary  for  carrying  out  a  wide 
range  of    system  functions. 

25.  ORGANIC  SUPPORT;  When  this  term  is  applied  to  weapon 
sysxem  computer  resources,  it  represents  the  manage- 
ment and  technical  support  at  an  AFLC  family  manned 
principally    by  government    personnel. 

26.  OPERATIONAL  SOFTWARE :  Generally,  operational  soft- 
ware which  automatically  performs  or  assists  in  the 
performance  of  a  navigation  cr  weapon  system  mission 
function.  Includes  Built-In-Test  (BIT)  logic  used  to 
evaluate  the  status  of  operational  equipment  and/or 
identify  faults  in  equipment  while  in  an  installed 
configuration . 
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27.  SOFTWARE:  Tha  instructions  or  procedures  a  computer 
recognizes  ("reads")  and  than  executes.  It  is  "soft" 
in  the  sense  that  it  is  easily  al-ered.  A  combina- 
tion of  associated  computer  programs  and  computer 
data  required  to  command  the  computer  equipmen-  to 
perform    computational   or   control   functions. 

28.  SOFTWARE  INTENSIVE:  Those  microprocessor  applica- 
tions in  which  the  function  can  vary  and  the 
application    software/firmware    is    subject   to   change. 

29.  SUPPORT  SOFTWARE:  Programs  which  aid  or  are  neces- 
sary in  the  preparation  cf  computer  programs  such  as 
editors,  compilers,  assemblers,  translators,  etc. 
which  may   or    may   not    exist    "on-line". 

30.  TFST  SOFTWARE :  Programs  which  contain  the  logic, 
stimuli  identification,  rasponse  evaluation,  and 
instructions  for  the  automatic  conduct  of  tests. 
Programs  used  to  analyze  the  data  collected  frcic  the 
conduct   of  tests. 

31.  VALIDATION;  As  used  herein,  validation  comprises 
those  evaluation,  integration,  and  test  activities 
carried  out  at  the  system  level  to  assure  that  the 
finally  developed  systems  satisfies  the  mission 
requirements    of  the    System   Specification. 

32.  VERIFICATION:  As  used  herein,  verification  is  the 
iterative  process  of  determining  whether  the  product 
of  selected  steps  in  the  CI  or  CPCI  development 
process  fulfills  the  requirements  of  each  step,  i.  9. , 
review,  audit,  test,  etc.,  ascertained  through  an 
appropriate  "verification  method"-  test,  demonstra- 
tion, inspection  or   analysis. 


89 


APPENDIX    C 
ECP    CLASSIFICATION 

Each  engineering  change  shall  be  assigned  the  appro- 
priate classification  by  the  originator.  Disagreements  as 
to  classification  between  intermediate  gcvernmenx  review 
activiriss  and  the  originator  may  be  appealed  to  -he  govern- 
ment   procuring    activity   for    decision. 

CLASS  I  ENGINEERING  CHANGE:  An  engineering  change  shall 
be  classified  Class  I  when  cne  or  more  of  the  factors  listed 
below    is   affected: 

1.  the  function  or  allocated  configuration  identifica- 
tion 

2.  The  product  configuration  identification  as  contrac- 
tually specified,  excluding  referenced  drawings, 
specifications,  listing  of  computer  program  instruc- 
tions and  actual   data   values 

NOTE:  In  the  above  definition  of  a  Class  I  engineering 
change,  the  words  "excluding  referenced  drawings,  specifica- 
tions, listing  of  computer  program  instructions,  and  actual 
data  values"  shall  net  be  interpreted  to  exclude  these  it sms 
prescribed  directly  in  a  contract  to  define  contract  line 
items.  Other  drawings,  specifications,  computer  program 
instructions  and  actual  data  values,  whether  referenced  in 
documents  or  listed  en  associated  lists  are  excluded  from 
the    above,    but    included   in    the   below    factors. 

3.  Technical  requirements  below  contained  in  the  Product 
Configuration  Identification  as  contractually  speci- 
fied, including  referenced  drawings  and 
specifications: 

a)    performance  outside    stated    tolerance 
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b)  reliability,  maintainability  or  survivability 
outsids  stated   tolerance 

c)  weight,    balance,    moment   of    inertia 

d)  interface    characteristics 
Non-technical    contractual    provisions 

a)  fee 

b)  incentives 

c)  cost    to  the  government 

d)  schedules 

e)  guaran-ees   or   deliveries 
Other  factors 

a)  government    furnished   equipment 

b)  safety 

c)  electromagnetic  characteristics 

d)  operational,  test    or   maintenance   computer   programs 

e)  compatibility  with  support  equipment,  -rainers  or 
training    devices/equipment 

f)  configuration  t.o  the  extent  that  retrofit  action 
would    be    taken 

g)  delivered  operation  and  maintenance  manuals  for 
which  adequate  change/revision  funding  is  net  on 
existing    contracts 

h)  pre-set  adjustments  or  schedules  affecting  oper- 
ating limits  or  performance  -co  such  extent  as  -o 
require  assignment   of   a   new   identification   number 

i)  interchangeabilit y,  suDstirutability  or  replace- 
ability        as     applied        -o      CI's,  and      to        all 

subassemblies  and  parts  or  repairable  CI*s, 
excluding  the  pieces  and  par-s  of  non-repairable 
subassemblies. 

j)  Sources  of  CI's  or  repairable  items  a-  any  level 
defined  by    source    control    drawings 

!^)  skills,  manning,  training,  biomedical  factors  or 
hunan   engineering    iesign 
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Ad  engineering  change  to  a  priva-ely  developed  i--=ffl 
shall  b9  classified  Class  I  when  it  affects  the  ccntractu- 
ally  £p9cified  form,  fit  or  function  of  the  item.  '.ihen  a 
greater  degree  of  control  is  negotiated  between  the  govern- 
ment and  the  contractor,  effects  on  ether  factors  may  be 
added  to  the  effects  en  form,  fit  oz  function  factors  which 
classify   an   engineering   change   as  Class    I. 

CLASS      II   ENGINEERING      CHANGE:  An   engineering      change 

shall   be     classified   class    II    when      it   does   not      fall   within 
the    definition   of   a   Class   I    engineering   change. 
Examples   of  a    Class  II    engineering    change   are: 

1.  a   change    in    documentation   only 

2.  a   change    in    hardware    which   does  not    affect    any    factor 
listed  under    Class   I    engineering   changes 
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APPENDIX    D 
CLASS     I    ECP   JOSTIFICATIOM    CODES 

Cedes  corresponding  with  ths  criteria  for  Class  I  engi- 
neering changes  for  necessary  or  beneficial  engineering 
changes  are  defined  in  the  following  subparagraphs.  If  one 
or  more  of  these  cedes  is  applicable  to  a  Class  I  engi- 
neering change,  the  one  which  is  the  most  descripxive  or 
significant  shall  be  assigned  zo  *he  EC?.  If  no  code  is 
pertinent,    the    ECP    is  not   desired. 

1.  CORRECTION  OF  DEFICIENCY  (CODE  D)  :  Cede  D  shall  be 
assigned  to  an  engineering  change  which  is  reguired 
to  eliminate  a  deficiency,  anless  a  more  descriptive 
separate  code  applies.  Such  separate  codes  are  used 
TC  identify  deficiencies  of  -he  nature  of  safety, 
interface  or    compatibility. 

2.  SAFETY  (CODE  S) :  Code  S  shall  be  assigned  to  an 
engineering  change  for  correction  of  a  deficiency 
which  is  required  primarly  to  eliminate  a  hazardous 
condition. 

3.  INTERFACE  (CODE  B)  :  Code  3  shall  be  assigned  to  an 
engineering  change  for  correction  of  a  deficiency 
which  will  eliminate  interference  or  incompatibility 
at   the  interface   between   configuration   items. 

U.  COMPATIBILITY  (CODE  C)  :  Code  C  shall  be  assigned  to 
an  engineering  change  for  correction  of  a  deficiency 
of  the  following   characteristics: 

a)  The  need  for  the  change  has  been  discovered  during 
the  system  or  item  functional  checks  or  during 
installation  and  checkout  and  is  necessary  to  make 
the  system   or   item   work,    and 
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b)  The  crigina-tor  in  assigning  zhs  ccmpatibili-y  cci  = 
is  declaring  that  the  effort  required  to  accom- 
plish the  change  is  considered  to  be  withir.  zhs 
scope  of  his  existing  contract,  and 

c)  Contractual  coverage  cocapleiiing  the  formal  docu- 
mentation of  the  engineering  change  will  not 
reflect  an  increase  in  contract  price. 

5.  OPERATIONAL  OR  LOGISTICS  SUPPORT  (CODE  0):  Cods  0 
shall  be  assigned  to  an  engineering  change  which  will 
make  a  significant  effectiveness  change  in  opera- 
tional or  logistics  support  requirements. 

6-  COST  REDUCTION  (CODE  R)  :  Code  R  shall  be  assigned  to 
an  engineering  change  which  will  provide  a  net  total 
cost  savings  to  the  Government,  including  not  only 
all  effects  en  cost  or  price  under  the  immediate 
contract  but  also  the  costs  resulting  from  necessary 
associated  changes  in  delivered  items,  logistic 
support  and  items  produced  by  others. 

7.  VALUE  ENGINEERING  (CODE  V)  :  Code  V  shall  be  assigned 
to  an  enginearing  change  which  will  effect  a  net  life 
cycle  cost  reduction  and  which  is  submitted  pursuant 
to  the  value  engineering  clause  of  the  contract. 

8.  PRODUCTION  STOPPAGE  (CODE  P) :  Code  P  shall  be 
assigned  to  an  engineering  ohange  which  is  required 
to  prevent  slippage  in  an  approved  production  sche- 
dule. This  code  applies  when  production  to  the 
current  configuration  identification  either  is 
impracticable  or  can  not  be  accomplished  without 
delay. 

9.  RECORD  ONLY  (CODE  A)  :  Code  A  shall  be  assigned  to  an 
engineering  change  which,  because  of  impact  en  tha  CI 
or  en  logistics  support,  is  a  Class  I  change,  but 
owing  to  the  contracting  method,  it  is  within  the 
scope  of  the  contract  and  should  not  be  processed  for 
fcrmal  change. 
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APPENDIX    E 
CLASS    I    ENGINEERING    CHANGE    PRIORITIES 

A   priority    shall      ba  assigned   to    each   Class      I    EC?    based 
upon      a      selection      from   the      following      definitions.  The 

priority  will  determine  the  relative  speed  at  which  th<=  ECP 
is  reviewed  and  evaluated,  and  at  which  the  engineering 
change  is  ordered  and  implemented.  The  proposed  priority  is 
assigned  by  the  originator  and  will  stand  unless  the 
procuring  activity  has  a  valid  reason  for  changing  the 
processing   rate. 

1.  EMERGENCY:  An  emergency  priority  shall  be  assigned 
to  an  engineering  change  proposed  for  either  of  the 
fcllcwing  reasons: 

a)  To  affect  a  change  in  operational  characteristics 
which,  if  not  accomplished  without  delay,  may 
seriously   compromise  the  national  security, 

b)  To  correct  a  hazardous  condition  which  may  result 
in  fatal  or  serious  injury  to  personnel  or  in 
extensive  damage  or  destruction  of  equipment.  A 
hazardous  condition  usually  will  require  with- 
drawing the  item  from  service  temporarily,  or 
suspension  of  the  item  operation,  or  discontin- 
uance of  further  testing  or  development  pending 
resolution   cf   the    condition- 

2.  URGENT:  An  urgent  priority  shall  be  assigned  to  an 
engineering  change  proposed  for  any  of  the  following 
reasons : 

a)  To  affect  a  change  in  operational  characteristics 
which,  if  not  accomplished  expeditiously,  may 
seriously  compromise  the  mission  effectiveness  of 
deployed    equipmant. 
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b)  Tc  correct  a  potaniiially  hazardous  condition,  the 
uncorrected  existence  of  which  could  result  in 
injury  to  personnel  or  damage  to  equipment,  A 
poTsntially  hazardous  condi-icn  compromises  safety 
and  emtodies  risk,  but  within  reasonable  limi-s, 
permitting  continued  use  of  the  effected  equipment 
provided  the  operator  has  been  informed  of  the 
hazard  and  appropriate  precauzions  have  been 
defined   and   distributed  to    the   user. 

c)  Tc  meet  significant  contractual  requirements 
(e.g.,  when  lead  time  will  necessitate  slipping 
approved  production,  activation  or  construction 
schedules    if  the    change  were   not    incorporated). 

d)  Tc  affect  an  interface  change  which,  if  delayed, 
would    cause  a   schedule   slippage   or   increase   cost. 

■3)    Tc  affect,    through   value  engineering  or   other  cost 

rsduction    efforts,      net   life      cycle  savings   to   the 

Government   of     a    total      or    mora     than   one      hundred 

thousand    dollars,         where    expedited      processing  of 

the  change     will    be      a   major      factor  in      realizing 

these    lower  costs. 

3.      ROUTINE:         A   routine    priority    shall      t^e  assigned   tc   a 

proposed    engineering    change   when      emergency    or   urgent 

-  is  not  applicable. 
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